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Abstract 


The Guidance and Control Software (GCS) project was the 
last in a series of software reliability studies conducted at 
Langley Research Center between 1977 and 1994. The technical 
results of the GCS project were recorded after the experiment 
was completed. Some of the support documentation produced as 
part of the experiment, however, is serving an unexpected role 
far beyond its original project context. Some of the software used 
as part of the GCS project was developed to conform to the 
RTCA/DO-178B software standard, "Software Considerations in 
Airborne Systems and Equipment Certification, " used in the civil 
aviation industry. That standard requires extensive 
documentation throughout the software development life cycle, 
including plans, software requirements, design and source code, 
verification cases and results, and configuration management 
and quality control data. The project documentation that 
includes this information is open for public scrutiny without the 
legal or safety implications associated with comparable data 
from an avionics manufacturer. This public availability has 
afforded an opportunity to use the GCS project documents for 
DO-178B training. This report provides a brief overview of the 
GCS project, describes the 4-volume set of documents and the 
role they are playing in training, and includes configuration 
management and quality assurance documents from the GCS 
project. 


1 Introduction and Background on Software Error Studies 

As the pervasiveness of computer systems has increased, so has the desire and obligation to 
establish the reliability of these systems. Reliability estimation and prediction are standard 
activities in many engineering projects. For the software aspects of computer systems, however, 
reliability estimation and prediction have been topics of dispute, especially for safety-critical 
systems. A primary challenge is how to accurately model the failure behavior of software such 
that numerical estimates of reliability have sufficient credibility for systems where the probability 
of failure needs to be quite small, such as in commercial avionics systems (ref. 1). A second 
challenge is how to gather sufficient data to make such estimates. Software reliability models are 
not used in the civil aviation industry, for example, because “currently available methods do not 
provide results in which confidence can be placed to the level required for this purpose.” (ref. 2) 

In an effort to develop methods to credibly assess the reliability of software for safety-critical 
avionics applications, Langley Research Center initiated a Software Error Studies program in 
1977 (ref. 3). A major focus of those studies was on generating significant quantities of software 
failure data through controlled experimentation to better understand software failure processes. 
The intent of the Software Error Studies program was to incrementally increase complexity and 
realism in a series of experiments so that the final study would have statistically valid results, 
representative of actual software development processes. 



The Software Error Studies program started with initial investigations by the Aerospace 
Coiporation to define software reliability measures and data collection requirements (ref. 4-6). 
Next, Boeing Computer Services (BCS) and the Research Triangle Institute (RT1) conducted 
several simple software experiments with aerospace applications including missile tracking, 
launch interception, spline function interpolation, Earth satellite calculation, and pitch axis 
control (refs. 7-11). The experiment design used in these studies generally involved a number of 
programmers (denoted n) who independently generated computer code from a given specification 
of the problem to produce n versions of a program. In these experiments, no particular software 
development standards or life-cycle models were followed. Because the problems were relatively 
small and simple, the versions were compared to a known error-free version of the program to 
obtain information on software errors. 

Although the initial experiments were small and simplistic compared with real-world avionics 
development, they yielded some interesting results that have influenced software reliability 
modeling. The BCS and RT1 studies showed widely varying error rates for faults. This finding 
refuted a common assumption in early software reliability growth models that faults produced 
errors at equal rates. These studies also provided evidence of fault interaction where one fault 
could mask potentially erroneous behavior from another fault, or where two or more faults 
together cause errors when alone they would not. (ref. 12) Additional investigations with n- 
version programs (ref. 13) found that points in the input space that cause an error can cluster and 
form “error crystals”. Extrapolating this finding to aerospace applications, where input signals 
tend to be continuous in nature, the error crystals may manifest themselves as clusters of 
successive faults that could have unintended consequences, (ref. 14) 

The last project in the Software Error Studies program was the Guidance and Control Software 
(GCS) project. It built on the previous experiments in two ways: (1) by requiring that the software 
specimens for the experiment be developed in compliance with current software development 
standards, and (2) by increasing the complexity of the application problem (ref. 15). At the time 
of the GCS project, the RTCA/DO-178B guidelines, "Software Considerations in Airborne 
Systems and Equipment Certification," (ref. 2) were the primary standard sanctioned by the 
Federal Aviation Administration (FAA) for developing software to be approved for use in 
commercial aircraft equipment (ref. 16). The DO-178B document describes objectives and 
design considerations to be used for the development of software as well as verification, 
configuration management, and quality assurance activities to be performed throughout the 
development process. The DO-178B guidelines were selected as the software development 
standard to be used for the GCS specimens. 

The software application selected for the GCS project, as the title indicates, is a guidance and 
control function for controlling the terminal descent trajectory of a planetary lander vehicle. This 
terminal descent trajectory is the same fundamental trajectory referred to as the “seven minutes of 
terror” in the entry, descent, and landing phase of a planetary mission, such as the recent Phoenix 
Mars Lander (ref. 17). For the GCS project, the software requirements were reverse engineered 
from a simulation program used to study the probability of success of the original NASA Viking 
Lander mission to Mars in the 1970s (ref. 18). It is important to emphasize that the software 
requirements documented for the GCS project, while realistic, are not the actual software 
requirements used for NASA’s Viking Lander or any other planetary landers. 

For the GCS experiment, two 1 teams of software engineers were each tasked to independently 
design, code, and verify a GCS program, following the software development guidance in DO- 
1786, as closely as possible. In addition to those teams, another GCS version was produced, 


1 The original plan for the GCS project called for three independent teams. Due to funding constraints, 
only two teams were able to complete the project. 
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without the constraint of compliance with DO-178B, to aid development and verification of the 
requirements and simulation environment. Once all versions were complete, data on residual 
errors was supposed to be collected by running all the versions simultaneously in a simulation 
environment, and using any discrepancies among the results of the versions as possible 
indications of errors. 

Results of the operational simulations and data collection are described in (ref. 15). The 
purpose of this report is not to repeat those results, but to disseminate some of the project 
documentation that has an unanticipated utility beyond its original project context. The project 
documentation of interest is the documentation developed by the teams required to comply with 
the DO-178B standard. That standard requires extensive records of all of the software 
development life cycle activities. For the GCS project, those records included 18 documents 
consisting of life cycle plans, development products including requirements and source code, 
verification cases and results, and configuration management and quality control data. 
Comparable data from a commercial avionics system would not be available for public review 
because of proprietary and other legal considerations. The GCS project documentation is not 
subject to those considerations because it is not data from an actual operational, or even 
prototype, system. But, the data has sufficient realism to provide a window into the types of 
activities and data involved in the production of DO-178 compliant software, which makes the 
GCS documentation desirable from a training perspective. 

The remainder of this report provides a brief overview of aspects of the GCS project relevant 
to using the documentation for training. This information includes a description of the GCS 
application, a synopsis of the software development processes used to follow the DO-178B 
guidance, and the data that was generated as a result. Because the complete set of compliance 
documents is large, the documents have been divided into four sets (planning, development, 
verification, and configuration management and quality assurance process documents) contained 
in separate volumes of this report. Volume 4 includes in Appendices A-F all of the GCS 
documents generated as part of the software quality assurance and configuration management 
activities, as well as an accomplishment summary. 

2 Guidance and Control Software Application 

The requirements for the GCS application focus on two primary functions: (1) to provide 
guidance and engine control of the lander vehicle during its terminal phase of descent onto the 
planet's surface, and (2) to communicate sensory information to an orbiting platform about the 
vehicle and its descent. Figure 1 shows a sketch of the lander vehicle, taken from (ref. 18), noting 
the location of the terminal descent propulsion systems. 

The guidance package for the lander vehicle contains sensors that obtain information about the 
vehicle state and environment, a guidance and control computer, and actuators providing the 
thrust necessary for maintaining a safe descent. The vehicle has three accelerometers (one for 
each body axis), one Doppler radar with four beams, one altimeter radar, two temperature 
sensors, three strapped-down gyroscopes, three opposed pairs of roll engines, three axial thrust 
engines, one parachute release actuator, and a touch down sensor. The vehicle has a hexagonal, 
box-like shape; three legs and a surface sensing rod protrude from its undersurface. 

In general, the requirements for the planetary lander only concern the final descent to the 
surface. Figure 2 shows a sketch of the phases of the terminal descent trajectory. 
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After the lander has dropped from orbit, the software controls the engines of the vehicle to the 
surface of a planet. The initialization of the GCS starts the sensing of vehicle altitude. When a 
predefined engine ignition altitude is sensed by the altimeter radar, the GCS begins guidance and 
control of the lander. The axial and roll engines are ignited; while the axial engines are warming 
up, the parachute remains connected to the vehicle. During this engine warm-up phase, the 
aerodynamics of the parachute dictate the vehicle’s trajectory. Vehicle attitude is maintained by 
firing the engines in a throttled-down condition. Once the main engines become hot, the 
parachute is released and the GCS performs an attitude correction maneuver and then follows a 
controlled acceleration descent until a predetermined velocity-altitude contour is crossed. The 
GCS then attempts to maintain the descent of the lander along this predetermined velocity- 
altitude contour. The lander descends along this contour until a predefined engine shut off 
altitude is reached or touchdown is sensed. After all engines are shut off, the lander free-falls to 
the surface. 

The software requirements for this guidance and control application are contained in a 
document called the Guidance and Control Development Specification (in Volume 2). As 
mentioned earlier, the initial requirements for this application were reverse engineered from a 
simulation program used to study the probability of success of the original NASA Viking Lander 
mission to Mars. Prior to use in the experiment, the requirements were revised to make them 
suitable for use in an //-version software experiment. Each of the GCS programs for the 
experiment were developed from the same requirements document. 

3 Software Life Cycle Processes and Documentation 

Having some of the project teams adhere to the DO-178B guidelines as they created a software 
version for the experiment was a significant element of the GCS project, requiring the 
development and tracking of numerous software engineering artifacts not normally associated 
with a software engineering experiment. The purpose of DO-178B is to provide guidelines for 
the production of software such that the completed implementation performs its intended function 
with a level of confidence in safety satisfactory for airworthiness. Along with the production of 
software is the generation of an extensive set of documents recording the production activities. 

DO-178B defines software development activities and objectives for the development life 
cycle of the software, and the evidence that is needed to show compliance. The life-cycle 
processes are divided into planning, development, and integral processes. The planning process 
defines and coordinates the software development processes and the integral processes. The 
software development processes involve identification of software requirements, software design 
and coding, and integration; that is, the development processes directly result in the software 
product. Finally, the integral processes function throughout the software development processes 
to ensure integrity of the software products. The integral processes include software verification, 
configuration management, and quality assurance processes. Section 11 of DO-178B describes 
data that should be produced as evidence of performing all of the life cycle process activities (see 
Table 1). 

For the GCS project, some of this data was common for all of the teams, and other data was 
intended to be specific to each team. For example, each team worked with the same plans, 
standards, and requirements. Then, each individual team was responsible for independently 
developing their own design, code, and corresponding verification data. To distinguish the 
versions, each team was assigned a planetary name: Mercury, Venus, and Pluto 2 . 


1 At the time the GCS experiment was conducted, Pluto had not yet been relegated to non-planet status. 
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Table 1. Life Cycle Data 


Planning Process 

Development Process 

Integral Process 

Documents 

Documents 

Documents 

• Plan for Software Aspects of 

• Software Requirements Data 

• Software Verification Cases and 

Certification 

• Design Description 

Procedures 

• Software Development Plan 

• Source Code 

• Software Verification Results 

• Software Verification Plan 

• Executable Object Code 

• Software Life Cycle Environment 

• Software Configuration 

Configuration Index 

Management Plan 


• Software Configuration Index 

• Software Quality Assurance 


• Problem Reports 

Plan 


• Software Configuration 

• Software Requirements 


Management Records 

Standards 


• Software Quality Assurance 

• Software Design Standards 


Records 

• Software Code Standards 


• Software Accomplishment 



Summary 


The DO-178B data associated with the development of the Pluto version of the GCS was 
selected for publication. Most of the GCS documents correspond directly with the life cycle data 
listed in Table 1. All together, the documentation includes over 1000 pages. So, for 
dissemination purposes, the Pluto data was divided into the following 4 subsets: 

Volume 1: Planning Documents 

• Plan for Software Aspects of Certification of the Guidance and Control Software Project 

• Software Configuration Management Plan for the Guidance and Control Software Project 

• Software Quality Assurance Plan for the Guidance and Control Software Project 

• Software Verification Plan for the Guidance and Control Software Project 

• Software Development Standards for the Guidance and Control Software Project 

Volume 2: Development Documents 

• Guidance and Control Software Development Specification 

• Design Description for the Pluto Implementation of the Guidance and Control Software 

• Source Code for the Pluto Implementation of the Guidance and Control Software 

Volume 3: Verification Documents 

• Software Verification Cases and Procedures for the Guidance and Control Software Project 

• Software Verification Results for the Pluto Implementation of GCS 

• Review Records for the Pluto Implementation of the Guidance and Control Software 

• Test Results Logs for the Pluto Implementation of the Guidance and Control Software 
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Volume 4: Other Integral Processes Documents 

• Software Accomplishment Summary for the Guidance and Control Software Project 

• Software Configuration Index for the Guidance and Control Software Project 

• Problem Reports for the Pluto Implementation of the Guidance and Control Software 

• Support Documentation Change Reports for the Guidance and Control Software Project 

• Configuration Management Records for the Guidance and Control Software Project 

• Software Quality Assurance Records for the Guidance and Control Software Project 

Appendices A thru F in this volume contain all of the original configuration management and 
quality assurance documents, except for planning, for the GCS Project. The Software 
Accomplishment Summary for the Guidance and Control Software Project , in Appendix A, 
provides a summary of how the project complied with the Plan for Software Aspects of 
Certification. Appendix B contains the Software Configuration Index for the Guidance and 
Control Software Project that lists all of the project’s data items under configuration control and 
also identifies the configuration of the software life cycle environment. Records of configuration 
management and quality assurance are provided in Appendix C ( Configuration Management 
Records for the Guidance and Control Software Project) and Appendix D ( Software Quality 
Assurance Records for the Guidance and Control Software Project). Finally, Appendix E 
contains all of the problem reports for the development artifacts (requirements, design, and source 
code); and Appendix F contains all of the change reports for the project’s support documentation. 

The content of the documents in the appendices has not been altered from the original versions 
produced during the project. 

4 Role in Training 

At the time of the GCS project, there was no publicly available information, such as templates, 
or examples, or training courses, to help a novice developer generate the type of evidence that a 
certificating authority would expect to see to demonstrate compliance with DO-178B. As 
mentioned earlier, compliance data from a real avionics system is not typically available for 
public review because of various legal and safety considerations. For example, an avionics 
manufacturer would likely consider the design and implementation of a system to be proprietary. 
Those considerations do not apply to the data from the GCS project, because neither the 
requirements nor the software versions represent an actual system with safety, liability, or other 
considerations. 

In addition to the availability of data, the GCS requirements and DO-178B compliance data 
are sufficiently realistic to serve as an example of a DO-178B project: one that is small enough in 
scale to be studied in a training course. The GCS documentation provides a window into the 
activities and data produced throughout the development life cycle to comply with DO-178B. 
Because the Federal Aviation Administration (FAA) was aware of the GCS project, they 
recognized the potential value of the documentation for training. The FAA has designed software 
training to include a case study portion that addresses avionics software issues that arise from the 
application of the DO-178B guidelines. The case study gives students the opportunity to use 
auditing techniques to identify flaws in lifecycle data. Because the GCS data was produced by 
novices, there are plenty of flaws to find. 
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5 Summary 

From 1977-1994, NASA Langley Research Center conducted a Software Error Studies 
program that generated data that provided insights into the software failure process and into 
conducting software engineering experiments as well. The GCS project was the final experiment 
in that program. A unique feature of the GCS project was the requirement for some of the 
software specimens used in the experiment to conform to the RTCA/DO-178B software standard, 
"Software Considerations in Airborne Systems and Equipment Certification," used in the civil 
aviation industry. The project documentation produced to meet that requirement has had the 
unanticipated benefit of serving as case study material in software certification training long after 
the conclusion of the original experiment. Volume 4 of this report contains all of the 
configuration management and quality assurance documents from the GCS project. Other 
volumes of this report contain the rest of the GCS compliance data including planning, 
development, and verification. 
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A.l Introduction 


The Guidance and Control Software (GCS) project is a research effort to investigate the faults 
that occur in the development and operation of software, especially software applications that 
conform to the Requirements and Technical Concepts for Aviation RTCA/DO-178B guidelines, 
"Software Considerations in Airborne Systems and Equipment Certification." To this extent, this 
project involved the production of two separate implementations of the GCS for the purpose of 
(1) collecting data on the faults that occur during the software development process, (2) collecting 
data on faults that occur in operational guidance and control software, and (3) making 
observations on the effectiveness of a development process that complies with the DO-178B 
guidelines. 

The GCS project was started originally in 1985 at the Research Triangle Institute (RTI) (ref. 
A. 1 ) with the development of the specification document for the guidance and control software 
application. The development of each of the two implementations described in this document 
started from a common specification of the requirements for the GCS (referred to as the GCS 
specification) and proceeded independently through the development of the design and code. 
Each GCS implementation was designed to run in conjunction with a software simulator that 
provides input to the implementation based on an expected usage distribution in the operational 
environment, provides response modeling for the guidance and control application, and receives 
data from the implementation. The GCS simulator is designed to allow an experimenter to run 
one or more implementations in a multitasking environment and collect data on the comparison of 
the results from multiple implementations. Certain constraints were incorporated in the GCS 
specification and project standards (especially standards regarding communication protocol) due 
to the nature of the GCS project. 

As stated in section 11.20 of DO-178B, the Software Accomplishment Summary is the primary 
data item used to show the certification authority compliance with the project’s Plan for Software 
Aspects of Certification. To this extent, this document contains an overview of the results of the 
GCS project, including: 

* an overview of the guidance and control application, 

* a statement of certification considerations, 

* a description of the characteristics of the final software products and the life cycle used to 
generate that product, 

* identification of the software configuration, 

* change history for the software products, 

* software status, and 

* compliance statement. 

In general, this document presents an overview of activities involved in developing the two 
GCS implementations, especially noting any deviations from the project plans delineated in the 
Plan for Software Aspects of Certification. Summaries of the life cycle processes and data are 
presented along with the identification of the final software products. The following section 
gives a general overview of the GCS project. 
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A.2 Overview of the Software Application 


According to DO-178B, the software requirements process uses the system requirements and 
system architecture to develop the high-level requirements for the desired software (ref. A.2). 
For the GCS project, however, there is no real system to be developed for use in a commercial 
aircraft system nor documentation of real system requirements. The GCS implementations will 
be executed only in a simulated operational environment to collect data for the research effort. 

As stated above, the GCS project started with the definition of software requirements for a 
specific component of a guidance and control system. The definition of the software 
requirements focused on two primary needs for the software: (a) to provide guidance and engine 
control of a lander vehicle during its terminal phase of descent onto the planet's surface and (b) to 
communicate sensory information to an orbiting platform about the vehicle and its descent. 

In general, the GCS is designed to control a planetary lander during its final descent to the 
planet’s surface. After the lander has dropped from orbit, the software will control the engines of 
the vehicle to the surface of a planet. The initialization of the GCS starts the sensing of vehicle 
altitude while the vehicle is in free-fall with its parachute attached. The aerodynamics of the 
parachute dictate the trajectory followed by the vehicle. When a predefined engine ignition 
altitude is sensed by the altimeter radar, the GCS begins guidance and control of the lander by 
igniting the axial and roll engines. While the axial engines are warming up, the parachute 
remains connected to the vehicle. Vehicle attitude is maintained by firing the engines in a 
throttled-down condition. Once the main engines become hot, the parachute is released and the 
GCS performs an attitude correction maneuver and then follows a controlled acceleration descent 
until a predetermined velocity-altitude contour is crossed. The GCS then attempts to maintain the 
descent of the lander along this predetermined velocity-altitude contour. The lander descends 
along this contour until a predefined engine shut off altitude is reached or touchdown is sensed. 
After all engines are shut off, the lander free-falls to the surface. Figure A. 1 shows the terminal 
descent phase of the lander. 

The lander vehicle to be controlled includes a guidance package containing sensors which 
obtain information about the vehicle state, a guidance and control computer, and actuators 
providing the thrust necessary for maintaining a safe descent. The vehicle has three 
accelerometers (one for each body axis), one Doppler radar with four beams, one altimeter radar, 
two temperature sensors, three strapped-down gyroscopes, three opposed pairs of roll engines, 
three axial thrust engines, one parachute release actuator, and a touch down sensor. The vehicle 
has a hexagonal, box-like shape with three legs as shown in Figure A.2 and a surface sensing rod 
protruding from its undersurface. 
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Figure A.l. A Typical Terminal Descent Trajectory 




Figure A.2. Lander Vehicle 




The software functions described above, as implemented in both GCS implementations, are 
the same as those described in the Plan for Software Aspects of Certification. The development 
of the two GCS implementations started with the release of version 2.2 of the GCS specification. 
During the course of the development effort described in the Plan for Software Aspects of 
Certification, there were thirty-seven modifications made to the GCS specification. Each of the 
modifications were accomplished through the Support Documentation Change Reporting (SDCR) 
procedures described in the Configuration Management Plan. Table A.l gives a summary of 
each of the SDCRs for the GCS specification. 
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Table A.l. Changes to the GCS Specification 


SDCR 

# 

Date 

Approve 

d 

Description of Change 

Module Affected 

2.2-1 

12/30/92 

Clarify initialization of PE INTEGRAL, 
YE INTEGRAL and TE INTEGRAL 

AECLP 

2.2-2 

12/30/92 

Clarify initialization of THETA 

RECLP 

2.2-3 

12/30/92 

Clarify rounding of AE CMD 

AECLP 

2.2-4 

2/8/93 

Remove unnecessary text in Table 5.10 

GP 

2.2-5 

2/24/93 

Add FRAMECOUNTER to list of input 
variables 

ARSP 

2.2-6 

3/10/93 

Correct the data type of elements in the data 
dictionary 

Data Dictionary 

2.2-7 

3/10/93 

Correct references to scalar and array variables 

AECLP 

2.2-8 

3/10/93 

Correct the listing of variables as control law 
parameters 

GP 

2.2-9 

5/20/93 

Add the definition of the term “data store” 

Introduction 

2.2-10 

5/27/93 

Add new structured analysis charts and 
corresponding explanation 

Level 0, Level 1 
Specifications 

2.2-11 

6/2/93 

Add new structured analysis charts at Level 2 
and corresponding changes 

Level 2 Specification 

2.2-12 

6/2/93 

Change all references to new structured analysis 
charts (many labeling/numbering changes) 

FOREWORD, Table of 
Contents, Lists of 

Figures and Tables, 
Introduction, Level 3 
Specification 

2.2-13 

6/2/93 

Change title to reflect numbering of new charts 
and correct list of inputs 

AECLP 

2.2-14 

6/2/93 

Change title to reflect numbering of new charts 
and correct list of inputs 

GSP 

2.2-15 

6/2/93 

Change title to reflect numbering of new charts 
and correct list of inputs 

RECLP 

2.2-16 

6/2/93 

Change title to reflect numbering of new charts 
and correct list of inputs 

TDLRSP 

2.2-17 

6/2/93 

Change title to reflect numbering of new charts 
and correct list of inputs 

TSP 

2.2-18 

6/3/93 

Change title to reflect numbering of new charts 

ARSP, ASP, CRCP, 
TDSP 

2.2-19 

6/3/93 

Add reference to Teamwork documentation 

Bibliography 

2.2-20 

6/3/93 

Change title to reflect new charts, delete 
unnecessary text 

GP 

2.2-21 

6/4/93 

Change title to reflect new charts and correct list 
of inputs 

CP 

2.2-22 

6/4/93 

Update description of structured analysis charts 

Appendix A 

2.2-23 

6/4/93 

Miscellaneous corrections to data element 
descriptions 

Data Dictionary 

2.2-24 

6/7/93 

Miscellaneous corrections to the data store 
descriptions 

Data Dictionary 


Related Change 
Reports 
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Table A.l (cont.). Changes to the GCS Specification 


SDCR 

# 

Date 

Approve 

d 

Description of Change 

Module Affected 

Related Change 
Reports 

2.2-25 

6/7/93 

Miscellaneous corrections to the descriptions of 
the control variables, data conditions, and 
initialization data 

Data Dictionary 


2.2-26 

6/7/93 

Clarify requirements for error handling when 
checking for upper and lower bound exceeded 

Introduction 


2.2-27 

1/13/94 

Clarify Runge-Kutte Method for the 
simultaneous equations 

Appendix C - Numerical 
Integration Instructions 


2.2-28 

2/15/94 

Clarify requirements for error handling when 
checking for upper and lower bounds exceeded 

Introduction 


2.2-29 

3/15/94 

Minor clarifications (defined acronyms, added 
table heading, etc.) 

All 

** This created version 
23 ** 


2.3-1 

5/13/94 

Minor clarifications and revisions 

Title Page and 

Introduction 


2.3-2 

5/19/94 

Change scheduling of the functional units and 
termination condition 

Introduction, ARSP, 

TDLRSP, CP 

Mercury PR# 1 4 

2.3-3 

6/9/94 

Minor corrections and clarifications 

Introduction, AECLP, 
ARSP, TDLRSP, CP 


2.3-4 

8/24/94 

Add statement for precision of floating point 
calculations, change form of standard deviation 
equation, correct data element descriptions 

Introduction, ASP, Data 
Dictionary 

Requirements- 
based Test Cases 
SDCR #4, 5, 6 , 7 

2.3-5 

9/23/94 

Correct Figure 1.1, correct input tables for 
ARSP, ASP, GP, TDSP, correct several data 
store location descriptions, 

Introduction, ARSP, 

ASP, GP, GSP, RECLP, 
TDLRSP, TDSP, Data 
Dictionary 

Mercury PR #25 

2.3-6 

12/21/94 

Up date Preface, Bibliography, and clarify 
calculation of the checksum 

Table of Contents, List 
of Tables, CP, Preface, 
Bibliography 

Requirements- 
based Test Cases 
SDCR # 8 , 11 

2.3-7 

3/15/94 

Clarify conditions for calculating mean and 
standard deviation, correct Table 5.9 and 5.10 to 
avoid square root of negative value 

ASP, GP 

Mercury PR# 30 
Requirements- 
based Test Cases 
SDCR #24, 25, 26 

2.3-8 


Format entire spec using Teamwork 




The following section concerns the certification aspects regarding this guidance and control 
application. 

A.3 Certification Considerations 

The two primary functions of the GCS are: (1) to provide guidance and engine control of the 
lander vehicle during its terminal phase of descent onto the planet's surface and (2) to 
communicate sensory information to an orbiting platform about the vehicle and its descent. 
Although there is not a system safety assessment for the GCS project, it was assumed that the loss 
of either of these functions could cause or contribute to a catastrophic failure condition for the 
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vehicle. Consequently, the guidance and control application as defined in the GCS specification 
was considered to be Level A software, requiring the highest level of effort to show compliance 
with the certification requirements. Since the GCS is assumed to be Level A, (as opposed to a 
lower level requiring less effort to show compliance), no justification for this rating is provided. 
This is consistent with the statement of certification considerations given in the Plan for Software 
Aspects of Certification. 

A.4 Software Characteristics 

As stated previously, two separate implementations of the GCS, referred to as Mercury and 
Pluto, were developed for this project. The size of the executable object code for each 
implementation is given in Table A.2. Because each implementation was designed only to run in 
conjunction with a software simulator that is instrumented to collect data to support the research 
(as opposed to having resource restrictions due to being part of a larger system), there were no 
special timing or memory requirements specified for the software. Further, it is difficult to 
differentiate the execution time of the implementation from the simulator running in a VAX/VMS 
environment. Consequently, the timing and memory data given in Table A.2 is the average time 
and maximum memory used over a number of trajectories. The average execution time was 
measured by taking the total time to run 100 trajectories and dividing by 100; and, the maximum 
working set size was measured by observing the largest working set used while running the 1 00 
trajectories. 


Table A.2. Software Characteristics 


Software Characteristic 


Pluto 

Executable Object Code Size 

32768 bytes 

24768 bytes 

Average Execution Time per Trajectory 

3.15 minutes 

1.04 minutes 

Maximum Working Set size per 
Trajectory 

205312 bytes 

198144 bytes 


A.5 Software Life Cycle Processes 

At a high level, the software life cycle processes for the GCS project consist of: the software 
planning process, the software development processes, and the integral processes. These 
processes, as described in the Plan for Software Aspects of Certification are given in Figure A.3. 
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Figure A.3. Flow of Life Cycle Activities for the GCS Project 



Software Quality Assurance 



Development Verification Configuration Software Quality Project Artifact 

Process Process Management Assurance Process (Life Cycle Data) 

Process 


The life cycle processes described in the Plan for Software Aspects of Certification and shown 
in Figure A.3 were accomplished in accordance with the plan with the exceptions. As previously 
stated, the requirements development process started with the revision of the GCS specification. 
The modification of the GCS specification was a significant effort and many changes were made 
following the release of version 2.2. Similarly, there was a significant effort involved in the 
modification of the RT1 generated designs to comply with the revised GCS specification. Due to 
the difficulties in working with previously generated designs and the number of problems 
identified in the first design reviews, two complete design reviews were held for each GCS 
implementation (a preliminary and final design review). In retrospect, the project would have 
progressed more quickly if the programmers were allowed to start their designs from scratch (as 
opposed to modifying an existing design). The coding and integration processes proceeded as 
planned. 
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There were also a number of personnel changes during the course of the GCS project. Most 
notably, there were changes to both the programmer and verification analyst roles. Table A.3 
lists all the individuals involved in the various project roles for the Mercury and Pluto 
implementations. 


Table A.3. GCS Project Participants and Their Roles 


Project Role 

Individuals Involved 

Proj ect Lead 

Kelly Hayhurst 

Software Quality Assurance 

Kelly Hayhurst, George Finelli, Carlos Liceaga 

Configuration Manager 

Laura Smith 

Mercury Programmer 

Ming Lin, Andy Boney 

Mercury Verification Analyst 

Debbie Taylor 

Pluto Programmer 

Paul Carter, Rob Angellatta, Philip Morris 

Pluto Verification Analyst 

Rob Angellatta, Patrick Quach 


A.5.1 Life Cycle Data 

The life cycle data specified in the Plan for Software Aspects of Certification were also 
produced. Table A.4 gives the list of that life cycle data. Each of the bulleted items in Table A.4 
represents distinct documents that will be delivered to the certification authority at the conclusion 
of the project. These documents will be available in paper form or can be made available in 
electronic form as needed. 

A.5.2 Relationship of Project Data 

As given in Table A.4, the planning documents document were used to set the course for the 
development and integral process activities. The Software Development Standards document was 
designed to be a project handbook — containing information about transition criteria for 
development activities, configuration management, problem reporting, and communication 
protocol in addition to the requirements, design and coding standards. Table A.5 shows the 
relationship of the project data to each other and to their relevant life cycle processes. 
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Table A.4. Life Cycle Data for the GCS Project 


Software Life Cycle Process 

Software Life Cycle Data 

Software Planning 

• Plan for Software Aspects of Certification including: 

Software Development Plan 

• Software Development Standards including: 

Software Requirements Standards 
Software Design Standards 
Software Code Standards 

• Software Configuration Management Plan 

• Software Quality Assurance Plan 

• Software Verification Plan 

Software Development 

• GCS Specification (Software Requirements Data) 

Transitional Software Requirements 

Transitional Software Design 

• Design Description for Mercury 

• Design Description for Pluto 

Software Coding 

• Source Code for Mercury 

• Source Code for Pluto 

Integration 

• Executable Object Code for Mercury 

• Executable Object Code for Pluto 

Integral 

• Software Verification Cases and Procedures including: 

Requirements-based Test Cases 

• Software Verification Results including: 

Structure-based Test Cases for Mercury 
Structure-based Test Cases for Pluto 

Software Verification 

Configuration Management 

• Software Configuration Index including: 

Software Life Cycle Environment Configuration Index 

• Software Configuration Management Records 

• Problem Reports for Mercury 

• Problem Reports for Pluto 

• Support Documentation Change Reports 

Software Quality Assurance 

• Software Quality Assurance Records 


• Software Accomplishment Summary 
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Table A.5. Relationship of Life Cycle Data 


Inputs 

Life Cycle Process 

Outputs 

DO-178B 

Software Planning 

Plan for Software Aspects of Certification 
Software Development Standards 
Software Verification Plan 
Software Configuration Management Plan 
Software Quality Assurance Plan 

GCS specification (as delivered from RTI) 

Requirements 

GCS specification version 2.2 

GCS specification version 2.2 

Software Development Standards 

Design Descriptions (as delivered from RTI) 

Design* 

Design Description for Mercury 
Design Description for Pluto 

GCS specification 

Design Descriptions for Mercury and Pluto 
Software Development Standards 

Code* 

Source Code for Mercury 
Source Code for Pluto 

Source Code for Mercury and Pluto 
Software Verification Cases and Procedures 
(including Requirements -based and 

Structure-based Test Cases) 

Integration* 

Executable Object Code for Mercury 
Executable Object Code for Pluto 

DO-178B 

GCS specification 

Software Verification Plan 

Design Descriptions for Mercury and Pluto 

Source Code for Mercury and Pluto 

Verification 

Software Verification Cases and Procedures 
Software Verification Results for Mercury 
Software Verification Results for Pluto 

DO-178B 

Software Configuration Management Plan 
All life cycle data 

Configuration 

Management 

Software Configuration Index (including the 
Life Cycle Environment Index) 

Problem Reports for Mercury 
Problem Reports for Pluto 
Support Documentation Change Reports 
Configuration Management Records 

DO-178B 

Software Quality Assurance Plan 
All life cycle data 

Software Quality 
Assurance 

SQA Records 


* Note that for these development processes, although the inputs and outputs for those processes 
have been grouped together in Table A. 5, the actual development processes were carried out 
independently by the separate development teams for the Mercury and Pluto implementations. 


A.6 Additional Considerations 

Without system requirements, certain assumptions were made in the development of the 
software requirements. Without system requirements, there also was no system safety assessment 
which is an important aspect of any development process that needs to comply with the DO-178B 
guidelines. Lack of system requirements also impacts the extent to which the project will comply 
with the DO-178B guidelines because no traces were made from the software requirements back 
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to the system requirements and safety assessment. These considerations are the same as those 
described in the Plan for Software Aspects of Certification. 


A.7 Software Identification 

The following tables contain the software configuration with respect to the current 
configuration identification and version number for the Mercury and Pluto implementations of the 
GCS. This is the identification of the elements as they are to be delivered to the certification 
authority. For each code component, the most recent version number and corresponding date 
when that component was placed under configuration control are given along with references to 
the problem reports to are related to the changes for that code component. 


Table A.6: Mercury Source and Executable Object Code Components 


Source Code 

D1SK$H0K1E: [GCS. CMS. SOURCE CODE.MERC 
URY] 

Version 

# 

Date 

Related 

Problem 

Reports 

aeclp.for 

3 

12/14/94 

25,26 

asp. for 

4 

3/24/95 

25,26, 30 

cp.for 

4 

12/29/94 

25, 26, 27 

excond.inc 

3 

12/14/94 

25,26 

gsp.for 

3 

12/14/94 

25,26 

param.inc 

3 

12/14/94 

25,26 

tdlrsp.for 

3 

12/14/94 

25,26 

tsp.for 

3 

12/14/94 

25,26 

arsp.for 

3 

12/14/94 

25,26 

common, inc 

3 

12/14/94 

25,26 

crcp.for 

3 

12/14/94 

25,26 

gp.for 

5 

3/24/95 

25, 26, 28, 30 

mercury, for 

3 

12/14/94 

25,26 

reclp.for 

3 

12/14/94 

25,26 

tdsp.for 

3 

12/14/94 

25,26 

Executable Object Code 

DISK$HOKIE : [GC S . CMS . EXEC OBJ CODE.MERCUR 
Y] 




mercury.exe 

1 

3/6/95 


build_mercury.com 

1 

3/6/95 



Although there were a total 6 problem reports issued for the Mercury source code(PRs # 25 - 
30), PR #29 did not result in any change to the source code. For the Pluto implementation, a total 
of 6 problem reports were also issued (PRs #23 - 28), each resulting in some change to the source 
code. 
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Table A.7: Pluto Source and Executable Object Code Components 


Source Code 

DISK$HOKIE: [GCS. CMS. SOURCE CODE.PLUTO 
] 

Version 

# 

Date 

Related 

Problem 

Reports 

aeclp.for 

4 

4/6/95 

23,24,28 

asp. for 

5 

4/6/95 

23,24, 27,28 

constants. for 

4 

4/6/95 

23,24,28 

crcp.for 

4 

4/6/95 

23, 24, 28 

gp.for 

5 

4/6/95 

23, 24, 27, 28 

gsp.for 

4 

4/6/95 

23, 24, 28 

pluto.for 

5 

4/6/95 

23, 24, 26, 28 

run_parameters.for 

4 

4/6/95 

23,24,28 

spsf.for 

4 

4/6/95 

23,24,28 

tdsp.for 

4 

4/6/95 

23,24,28 

utility, for 

4 

4/6/95 

23, 24, 28 

arsp.for 

4 

4/6/95 

23,24,28 

clpsf.for 

5 

4/6/95 

23, 24, 26, 28 

cp.for 

5 

4/6/95 

23,24, 25,28 

external, for 

4 

4/6/95 

23,24,28 

gpsf.for 

4 

4/6/95 

23,24,28 

guidance state, for 

4 

4/6/95 

23,24,28 

reclp.for 

4 

4/6/95 

23, 24, 28 

sensoroutput.for 

4 

4/6/95 

23, 24, 28 

tdlrsp.for 

4 

4/6/95 

23, 24, 28 

tsp.for 

4 

4/6/95 

23,24,28 

Executable Object Code 

DISK$HOKIE: [GCS. CMS. EXECOBJCODE. PLUTO] 




pluto.exe 

1 

6/1/95 


p_build.com 

1 

6/1/95 



A.8 Change History 

Problem Reporting for the GCS project was divided into 2 distinct areas: reports for software 
products and reports for support documentation. The life cycle data items contained in each of 
these categories are listed in Table A.8 and A.9. The life cycle data in the development products 
and support documentation categories are all under CC 1 . A unique problem and change reporting 
system was established for each category. Two different reporting systems were used because, 
from an experiment perspective, we wanted to collect additional information about the errors in 
the development products than was required by DO-178B. In general, information on changes 
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made to the support documentation was not a focus of the experiment. Further information about 
the problem reporting procedures and forms can be found in the Software Development Standards 
and the Software Configuration Management Plan. 


Table A. 8. Development Products 


Design Description 
Source Code 
Executable Object Code 


Table A.9. Support Documentation 


Plan for Software Aspects of Certification 

Software Development Plan 

Software Requirements Standards 

Software Design Standards 

Software Code Standards 

Software Accomplishment Summary 

Software Verification Plan 

Software Verification Cases and Procedures 

Software Quality Assurance Plan 

Software Configuration Management Plan 

Software Life Cycle Environment Configuration Index 

Software Configuration Index 

Software Requirements Data 


A.8.1 Summary of Development Activities and Problem Reports 

The following tables contain brief summaries of the development activities and problem 
reports issued for the Mercury and Pluto implementations of GCS. Tables A. 10 and A. 11 give 
the development and problem report summaries for the Mercury implementation and Tables A. 12 
and A. 13 give the summaries for the Pluto implementation. For the problem report summaries, 
the following information is given in the tables: 

• the development product in which the problem was first identified (Design, Source Code, 
Executable Object Code) 

• specific code components affected by the change (including Introduction, Fligh-level 
Diagrams, Functional Units, and Data Dictionary) 

The functional units are: 
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Axial Engine Control Law Processing (AECLP), 

Altimeter Radar Sensor Processing (ARSP), 

Accelerometer Sensor Processing (ASP), 

Communications Processing (CP), 

Chute Release Control Processing (CRCP), 

Guidance Processing (GP), 

Gyroscope Sensor Processing (GSP), 

Roll Engine Control Law Processing (RECLP), 

Touch Down Landing Radar Sensor Processing 
(TDLRSP), 

Touch Down Sensor Processing (TDSP), and 
Temperature Sensor Processing (TSP). 


• activity that enabled the discovery of the problem (Design Review, Code Review, 
Testing, Requirements change, or Other) 

• brief description of the problem (Missing, Unnecessary or Incorrect Lunctionality; 
Ambiguity in information, comments or syntax; Cosmetics including typographical and 
grammatical errors; and Noncompliance with standards) 

• related change reports 

Note that a number of specific problems were often addressed in a single problem report. 
Although combining multiple problems into one report makes description of the problems 
cumbersome, it was considered necessary to reduce the amount of paperwork involved in the 
change control process, especially when a large number of problems were identified in the early 
review sessions. Lor further information on the problem descriptions, see the problem reports for 
each specific GCS implementation. 
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T able A. 1 0. Summary of Mercury Development Activities 


Development 

Phase 

Dates 

Product 

Verification Activities 

Related 

Problem Reports 

Design 

11/93 - 
5/31/94 

Preliminary 

Design 

• Preliminary Design Review: 
Overview 12/2/93 
6 Review Sessions 12/7-10/93 

PRs #1 -13 

• GCS specification mod SDCR 2.3-2 

PR# 14 

5/31/94 - 
8/30/94 

Design 

• Design Review: 

Overview 6/3/94 
2 Review Sessions: 6/29/94 

PRs #15 -22 

• GCS specification mod SDCR 2.3-4 

PR# 23 

Code 

8/30/94 - 
12/10/94 

Mercury 
Source Code 

• Programmer identified problems in 
design while developing code 

PR #24 

• Code Review: 

Overview 10/4/94 
2 Review Sessions 10/19/94 

PRs #25 - 26 

Integration 

12/10/94 - 
4/15/95 

Executable 
Object Code 

• GCS specification change SDCR 
#2.3-6 

PR #27 

• Requirements-based Testing: 
Functional Unit Level 
Subframe Level 
Frame Level 
Trajectory Level 

PR #28 

• Structure -based Testing 

PR #29 (determined 
to not be a problem) 

• GCS specification mod SDCR #2.3-7 

PR #30 
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Table A. 1 1 . Summary of Problem Reports for Software Products for Mercury 


PR 

# 

Product 

Product Component 

Discovery Activity 

Description 

1 

Preliminary 

Design 

ASP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity 

2 

Preliminary 

Design 

GSP 

Design Review 

Missing functionality, Cosmetics 

3 

Preliminary 

Design 

TSP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity, Cosmetics 

4 

Preliminary 

Design 

ARSP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity, Cosmetics 

5 

Preliminary 

Design 

TDLRSP 

Design Review 

Unnecessary and Incorrect functionality, Cosmetics 

6 

Preliminary 

Design 

TDSP 

Design Review 

Unnecessary and Incorrect functionality, 
Ambiguity 

7 

Preliminary 

Design 

GP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity 

8 

Preliminary 

Design 

AECLP 

Design Review 

Missing, Unnecessary, and Incorrect functionality 

9 

Preliminary 

Design 

RECLP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity 

10 

Preliminary 

Design 

CP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity 

11 

Preliminary 

Design 

Data Dictionary 

Design Review 

Incorrect functionality, Ambiguity 

12 

Preliminary 

Design 

ASP, ARSP, CP 

Design Review 

Cosmetics 

K9 

Design 

High-level Diagrams 

Design Review 

Incorrect functionality 


Design 

ARSP, TDLRSP, CP 

Requirements Change 

Update to GCS specification mod (scheduling) 

D 

Design 

High-level Diagrams 

Design Review 

Incorrect functionality, Ambiguity 

16 

Design 

High-level Diagrams, 
Data Dictionary 

Design Review 

Missing and Incorrect functionality 

17 

Design 

ASP, GSP, TSP, ARSP, 
TDLRSP, TDSP 

Design Review 

Unnecessary and Incorrect functionality 

18 

Design 

GP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity, Cosmetics 

o 

Design 

AECLP, RECLP 

Design Review 

Missing, Unnecessary, and Incorrect functionality 

20 

Design 

CP 

Design Review 

Unnecessary and Incorrect functionality, 
Ambiguity 

21 

Design 

Complete Design 

Design Review 

Incorrect functionality (with respect to limit 
checks) 

22 

Design 

Data Dictionary, 
Introduction 

Design Review 

Cosmetics 

23 

Design 

ASP 

Data Dictionary 

Requirements Change 

Update to GCS specification mod (calculation of 
standard deviation & data dictionary entries) 


Design 

Complete Design 

Generating code 

Incorrect functionality 


Design, Code 

Design & Code 

Code Review 

Incorrect functionality, Cosmetics 


Code 

Code 

Code Review 

Unnecessary functionality, Cosmetics 


Design, Code 

CP 

Requirements Change 

Update to GCS specification mod 

28 

Design, Code 

GP 

Requirements-based 
testing (Functional unit 
level) 

Incorrect functionality 

29 

Code 

RECLP 

Generating structure- 
based test cases 

problem was suspected but found not to be a 
problem 

30 

Design, Code 

ASP, GP 

Requirements Change 

Update to GCS specification mod (change in 
standard deviation and Tables 9 & 10) 


Related Reports 


PRs # 1,4, 10 

PRs # 1 - 12 
SDCR# 2.3-2 
PR #13 


PRs #1,2, 3,4, 

16 

PR #7 

PRs #8, 9, 16 
PR #10 


SDCR# 2.3-4 


SDCR# 2.3-5 

SDCR# 2.3-6 
PRs #7, 18 


SDCR# 2.3-7 
SDCR# 2.3-4 
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Table A. 12. Summary of Pluto Development Activities 


Development 

Phase 

Dates 

Product 

Verification Activities 

Related 

Problem Reports 

Design 

11/93 - 
6/29/94 

Preliminary 

Design 

• Preliminary Design Review: 

Overview 8/26/93 

9 Review Sessions 9/16/93 - 10/15/93 

PRs #1 -13 

• GCS specification mod SDCR 2.3-2 

PR# 14 

6/29/94 - 
8/26/94 

Design 

• Design Review: 

2 Review Sessions: 7/13/94 

PRs #15- 19 

Code 

8/26/94 - 
12/5/94 

Pluto Source 
Code 

• GCS specification mod SDCR 2.3-4 

PR# 20 

• Code Review: 

Overview 10/26/94 
2 Review Sessions 11/16/94 

PRs #21 -23 

Integration 

12/5/94 - 
4/15/95 

Executable 
Object Code 

• Requirements-based Testing: 
Functional Unit Level 
Subframe Level 
Frame Level 
Trajectory Level 

Prs #24 & 25 

PR# 26 
PR# 27 

• Structure -based Testing 
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Table A. 1 3 . Summary of Problem Reports for Pluto 


PR 

# 

Product 

Affected Component 

Discovery Activity 

Description of the Problem 

1 

Preliminary 

Design 

Complete Design 

Design Review 

Noncompliance with standards (design did not 
balance) 

2 

Preliminary 

Design 

High Level Diagrams 

Design Review 

Unnecessary functionality 

3 

Preliminary 

Design 

TSP 

Design Review 

Unnecessary and Incorrect functionality, 
Ambiguity 

4 

Preliminary 

Design 

ARSP 

Design Review 

Missing and Unnecessary functionality, Ambiguity 

5 

Preliminary 

Design 

ASP 

Design Review 

Ambiguity 

6 

Preliminary 

Design 

GSP 

Design Review 

Incorrect functionality, Ambiguity 

7 

Preliminary 

Design 

TDLRSP 

Design Review 

Missing, unnecessary, and incorrect functionality, 
Ambiguity, and Cosmetics 

8 

Preliminary 

Design 

TDSP 

Design Review 

Unnecessary and Incorrect functionality 

9 

Preliminary 

Design 

RECLP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity 

10 

Preliminary 

Design 

AECLP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity 

11 

Preliminary 

Design 

CP 

Design Review 

Missing and Incorrect functionality, Ambiguity, 
Noncompliance with standards 

12 

Preliminary 

Design 

GP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity 

13 

Preliminary 

Design 

High Level Diagrams, Data 
Dictionary 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity 

14 

Design 

ARSP, TDLRSP 

Requirements change 

Update to GCS specification mod (scheduling) 

15 

Design 

ARSP, ASP, TDLRSP, 
TSP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity 

16 

Design 

RECLP, AECLP, CRCP, 
CP 

Design Review 

Unnecessary and Incorrect functionality, 
Ambiguity, and Cosmetics 

17 

Design 

High Level Diagrams, Data 
Dictionary 

Design Review 

Missing and Incorrect functionality, , 
Ambiguity, Cosmetics 

18 

Design 

GP 

Design Review 

Missing, Unnecessary, and Incorrect functionality, 
Ambiguity 

19 

Design 

Complete Design 

Design Review 

Incorrect functionality, Ambiguity 

20 

Design 

High Level Diagrams, CP, 
Data Dictionary 

Requirements Change 

Update to GCS specification mod 

21 

Design 

Introduction, High Level 
Diagrams, Data Dictionary 

Code Review 

Incorrect functionality, Cosmetics 

22 

Design 

Complete Design 

Code Review 

Unnecessary and Incorrect functionality, 
Ambiguity, Cosmetics 

23 

Code 

Complete Code 

Code Review 

Missing, Unnecessary, and Incorrect functionality, 
Cosmetics, Noncompliance with standards 

24 

Code 

ARSP, GP, RECLP, 
TDLRSP, TSP 

Requirements-based 
Functional Unit Tests 

Incorrect functionality 

25 

Code 

CP 

Requirements-based 
Functional Unit Tests 

Incorrect functionality 

26 

Code 

Subframe & Frame 

Prep for Requirements- 
based Subframe & Frame 
Tests 

Cosmetics 

27 

Code 

ASP, GP 

Requirements-based 
Trajectory Tests 

Incorrect functionality (negative square root 
problem) *** Initiated SDCR# 2.3-7 

28 

Code 

Complete Code 

Requirements-based 
Functional Unit Tests 

Compiling problem (code was incorrectly 
transferred from one machine to another) 


Related 

Reports 


SDCR# 2.3-2 

PR #17 

SDCR# 2.3-4 
PR #20 

PR #23 
SDCR# 2.3-7 
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A.9 Software Status 


No problem reports for the software products from either the Mercury or Pluto 
implementations are unresolved; that is, all problem reports have been completed and approved. 
In fact, as per the transition criteria for the development processes, all problem reports issued 
during a given development process had to be completed and approved before the next 
development process could begin. 

A. 10 Compliance Statement 

The development of the two GCS implementations proceeded for the mostpart as directed in 
the GCS project planning documents and proceeded, to the best of our understanding, in 
compliance with the standards in DO-178B. The two major deviations were in project personnel 
and schedule, with the changes in personnel having a substantial impact on the project schedule. 
The software development plan was executed as described in the Plan for Software Aspects of 
Certification. No further modifications of the software development products are planned. 
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Appendix B: Software Configuration Index for the Guidance and 
Control Software Project 

(includes the Software Life Cycle Environment Configuration Index) 

Authors: Laura J. Smith and Kelly J. Hayhurst, NASA Langley Research 
Center 


This document was produced as part of Guidance and Control Software (GCS) Project conducted at 
NASA Langley Research Center. Although some of the requirements for the Guidance and Control 
Software application were derived from the NASA Viking Mission to Mars, this document does not 
contain data from an actual NASA mission. 
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B.l Introduction 


The Software Configuration Index (SCI) functions as a master list for the configuration of 
items under configuration control for the Guidance and Control Software (GCS) project. The 
Software Life Cycle Environment Configuration Index (SECI) identifies the configuration of the 
software life cycle environment. This document contains both the Software Configuration Index 
and the Software Life Cycle Environment Configuration Index as described in sections 11.16 and 
11.15 of DO-178B, respectively. 

The Software Configuration Index identifies the configuration of the software product. The 
SCI should identify the following: 

• the software product; 

• executable object code; 

• each source code component; 

• software life cycle data; 

• archive and release media; 

• instructions for building the executable object code; 

• procedures used to recover the software for regeneration, testing, or modification; 

• reference to the Software Life Cycle Environment Configuration Index if packaged 
separately; and 

• data integrity checks for the executable object code, if used. 

Configuration management for on-line files for GCS is aided by the DEC Code Management 
System (CMS) (ref. B.l). For more information on how CMS is being used during this project, 
refer to the Software Configuration Management Plan. A complete list of tools used in the GCS 
project can be found in the Software Life Cycle Environment section of this document. 

B.2 Software Product 

For the purpose of the GCS project, the software product refers to executable object code, each 
source code component, and the software life cycle data. The following sections describe each 
component of the software product in further detail. 

B.2.1 Executable Object Code 

The executable object code will not be placed under configuration control until the integration 
phase of development is complete. For all of the testing during the integration phase, the source 
code will be fetched from CMS and the executable object code will be generated as defined in the 
Software Verification Procedures. Once all testing is complete, the executable object code will 
be generated using the appropriate build files for each implementation (see section “Instructions 
for Building Executable Object Code”) and placed in the designated CMS library (see Table B.3). 
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B.2.2 Source Code Components 


Two implementations (referred to as Mercury and Pluto) of the GCS are being developed 
independently for this project. Table B. 1 lists the source code components for Mercury and Table 
B.2 lists the source code components for Pluto. Each implementation has its own CMS library 
which is located in the VMS directory DISK$HOKIE:[GCS.CMS.SOURCE_CODE.j3/anet] 
where planet refers to Mercury or Pluto. The individual source code components are located in 
this library for each implementation. 


Table B.l: Mercury Source Code Components 


Library: 

D1SK$H0KIE: [GCS. CMS. SOURCECODE. MERCURY] 

aeclp.for 

arsp.for 

asp. for 

common.inc 

cp.for 

crcp.for 

excond.inc 

gp.for 

gsp.for 

mercury, for 

param.inc 

reclp.for 

tdlrsp.for 

tdsp.for 

tsp.for 



Table B.2: Pluto Source Code Components 


Library: 

DISK$HOKIE: [GCS. CMS. SOURCECODE. PLUTO] 

aeclp.for 

arsp.for 

asp. for 

clpsf.for 

constants. for 

cp.for 

crcp.for 

external, for 

gp.for 

gpsf.for 

gsp.for 

guidance state, for 

pluto.for 

reclp.for 

run_parameters.for 

sensoroutput.for 

spsf.for 

tdlrsp.for 

tdsp.for 

tsp.for 

utility, for 



B.2.3 Software Life Cycle Data 

For the GCS project, the general plan for configuration management is to use a set of software 
tools, already available at Langley, and some paper forms to identify, control, baseline, and 
archive all life cycle data associated with the development of the GCS implementations. Table 
B.3 gives a list of the life cycle data for the GCS project as discussed in Section 1 1 of the DO- 
1786 guidelines plus additional life cycle data as required by the project. This life cycle data 
consists of planning and support documents and the actual products from the software 
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development process (e.g., design description and source code). Configuration management is 
responsible for maintaining all changes made to this life cycle data throughout the GCS project. 


Table B.3. Life Cycle Data for the GCS Project 


Software Life Cycle Data 

Configuration Item 

Storage Medium* 3 ' 

Plan for Software Aspects of Certification 
Software Development Plan 

Plan for Software Aspects of 
Certification 

CERTPLAN 

Software Verification Plan 

Verification Plan 

Software Requirements Traceability Data 

VERPLAN 

TRACEDATA 

Software Configuration Management Plan 

Configuration Management Plan 

CMPLAN 

Software Quality Assurance Plan 

Software Quality Assurance Plan 

SQAPLAN 

Software Requirements Standards 
Software Design Standards 
Software Code Standards 

Software Development Standards 

DEVSTAND 

Software Requirements Data 

GCS Specification 

SPEC 

Design Description 

Teamwork Model* 
Design Overview* 

DES_DESCRIP./;/«nef 

Source Code 

Source Code* 

SOURCECODE.p/aiiet 

Executable Object Code 

Executable Object Code* 

EXEC_OBJ_CODE.p/awet 

Software Verification Cases and Procedures 

Verification Cases* 
Verification Procedures 

VERCASES 

VERPROC 

Software Verification Results 

Verification Results* 

VER_RESULTS./j/a«et 

Software Life Cycle Environment 
Configuration index; 

Software Configuration index 

Configuration index 

CONFIGINDEX 

Problem Reports 

Problem and Action Reports* 
Support Document Change Reports 
Formal Modifications to the 
Specification 11 ’* 

paper forms 
paper forms 
SPECMODS 

Software Configuration Management 
Records 

Configuration Management Records* 

paper forms 

Software Quality Assurance Records 

Software Quality Assurance Records* 

paper forms 

Software Accomplishment Summary 

Software Accomplishment Summary 

ACCOMPSUM 

Simulator User's Guide 

Simulator User's Guide 

SIMULATORS SER GUID 
E 

Simulator Source Code 

Simulator Source Code 

SIMULATOR. SOURCE C 
ODE 


(a) All CMS libraries are located in DISK$HOKlE:[GCS.CMS.xxx] where xxx is specified under storage medium. 


<b) Formal modifications 2.2-1 through 2.2-26 of the GCS Specification were not recorded in Support 
Documentation Change Reports (SDCR). All remaining modifications to the GCS Specification will be 
recorded on an SDCR form. 

* These configuration items will be implementation specific, the labels should refer to the implementation as 
appropriate. 
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B.2.4 Archive and Release Media 


The items under configuration management using CMS for the GCS project are kept on-line 
on a DEC VAX cluster, running the VMS operating system. The following describes the backups 
of this system to ensure the integrity of the data: 

• a full backup of all items located on the system will be performed once a week; 

• a duplicate copy will be made of each full backup tape and stored in a physically separate 
archive to minimize the risk of loss in the event of a disaster; 

• no unauthorized changes can be made to any of the backup tapes; 

• all tapes will be verified for regeneration errors (by using the backup/verify command); 

• incremental backups are run on a daily basis for a four week cycle to lessen the probability of 
losing any information. 


After a full backup has been performed, a duplicate copy of the tape will be made. The 
duplicate tapes are verified when copied to ensure that accurate copies have been produced. The 
components of the GCS project will be authorized for release to the certification authority after 
the integration testing has been completed. All data will be archived for future references. 

Since Problem Reports and Support Documentation Change Reports are not kept 
electronically, they will be archived in a binder by the configuration manager. Only PRs and 
SDCRs that have been approved and signed by the SQA representative will be archived. There 
will be separate binders labeled "Problem Reports for Planet", for each implementation, and 
“Change Reports”. The SDCRs are organized by configuration item. See the section on 
"Configuration Status Accounting" in the Software Configuration Management Plan for more 
details on the binders. 

B.2.5 Instructions for Building the Executable Object Code 

The programmer for each implementation is responsible for the file that contains instructions 
for how all of the source code elements must be linked together in order to run the files. The 
Mercury build file is mercury_compile.txt. The Pluto build file is list_of_routines.txt. Each build 
file is stored in their respective CMS libraries, 

DISK$HO!OE:[GCS.CMS.SOURCE_CODE./?/anef]. A copy of each build file is given is 
Appendix B. 

B.2.6 Procedures Used to Recover the Software for Regeneration, Testing, or 
Modification 

When a configuration item is requested from the Configuration Manager, it is placed in a 
VMS directory. However, not all of the project’s life cycle data is developed or modified on the 
VAX system. For example, most of the planning and support documentation is developed using 
Microsoft Word on a Macintosh, and the implementations’ designs are developed using a tool 
called Team work that runs on a SUN workstation. Some special instructions are needed to ensure 
that all project data can be regenerated and modified. The following subsections describe the 
procedures for transferring files to/from a VMS directory to their native format. 
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B.2.6.1 Instructions for Text Documents 


Most of the planning documents are developed using Microsoft Word and these documents 
can be transferred to the VAX for configuration management using the FTP tool. The document 
must be transferred to the appropriate directory on the VAX system called A1R19 (all project 
members will have a valid account on this system). When transferring a Microsoft Word 
document using FTP, the options Image and MacBinary must be selected to ensure that the 
document can be regenerated as a Word document. 

B.2.6.2 Instructions for Teamwork Models 

As stated above, the Teamwork tool (running on a SUN workstation) is used to develop and 
modify the design description for each implementation. Preparing a Teamwork model for 
configuration management involves extracting the model from the Teamwork database and 
properly transferring the resulting file to A1R19. Teamwork models are either complete or 
incremental. A complete model contains all of its own objects; that is, it is self-contained, hence 
the term complete. An incremental model records only modifications made to objects stored in 
some other model; it is not self-contained. All Teamwork models under configuration 
management for the GCS project will be complete models. When archiving an incremental 
model, the incremental model as well as all referenced models must be archived as a unit in order 
to preserve the ability to reconstruct the incremental model. 

The second column of the Teamwo/Ws "Model Processes Index" display indicates if a model is 
complete or incremental. When preparing a Teamwork model for configuration management, 
first complete the model if necessary. 

Once the model is completed, the "dump tsa" utility is invoked to extract the Teamwork 
model from the Teamwork database into a dump file. A dump file is merely an operating system 
file in a specific format. Once a dump file for the model has been created, the "dump" file should 
be transferred to A1R19. The FTP utility provides a convenient means for transferring the dump 
file. Note, the binary mode of FTP must be used in order to preserve the file integrity. 

After requesting the Teamwork model from configuration management for testing or 
modification, the FTP utility can be used to transfer the Teamwork model from A1R19 to the 
machine which has Teamwork loaded. The binary mode of ftp should be invoked. Once the file 
containing the Team work model resides on the machine, the "loadtsa" utility should be used to 
load the dump file into Team work. 

B.2.6.3 Instructions for Source Code and Test Cases 

The source code and test cases are created either on a VAX or on a SUN, depending on the 
participants workstation. For those cases where source code or test cases are created on the SUN, 
the files are transferred to A1R19 (the development workstation) via the FTP utility for 
compilation, linking, executing, etc. No special conversion instructions are necessary before 
storing the files in CMS. 

B.2. 6.4 Native Format of Configuration Items 

Table B.4 shows the configuration items along with the format in which they are stored in the 
CMS libraries, if applicable. Some of the configuration items are only kept in paper form; these 
will be archived and available for future references. 
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Table B.4: Native Format of Configuration Items 


Configuration Items 

Format 

Plan for Software Aspects of Certification 

Microsoft Word 

Verification Plan 

Microsoft Word 

Software Requirements Traceability Data 

Microsoft Word 

Configuration Management Plan 

Microsoft Word 

Software Quality Assurance Plan 

Microsoft Word 

Software Development Standards 

Microsoft Word 

GCS Specification 

Microsoft Word 

T earn work Model 

Team work 

Design Overview 

Microsoft Word 

Source Code 

FORTRAN 

Executable Object Code 

VMS Executable Image 

Verification Cases 

models: Mathematica 
test cases: ASCII 

Verification Procedures 

Microsoft Word 

Verification Results 

Microsoft Word 

Configuration Index 

Microsoft Word 

Problem and Action Reports 

paper 

Support Document Change Forms 

paper 

Formal Modifications to the Specification 

Microsoft Word 

Configuration Management Records 

paper 

Software Quality Assurance Records 

paper 

Software Accomplishment Summary 

Microsoft Word 

Simulator User's Guide 

Microsoft Word 

Simulator Source Code 

FORTRAN 


B.3 Software Life Cycle Environment Configuration Index 

The Software Life Cycle Environment Configuration Index (SEC1) identifies the configuration 
of the software life cycle environment. This index is written to aid reproduction of the hardware 
and software life cycle environment for software regeneration, reverification, or modification, and 
should identify the following: 

• the software life cycle environment hardware and its operating system software; 

• the software development tools, such as compilers, linkage editors and loaders, and data 
integrity tools; 

• the test environment used to verify the software product; and 

• qualified tools and their associated tool qualification data. 
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B.3.1 Software Life Cycle Environment Hardware and its Operating System 


Since the development of the GCS implementations is part of a research project, the 
development environment for the software is the same as the target environment of the 
implementations; that is, the GCS implementations will not be included in a "real" hardware 
system intended for space flight. The environment for most of the software development of the 
GCS implementations is a microVAX 3800 computer system (referred to as A1R19). However, 
the Teamwo/A software is located on a Sun 4/3 10C machine which runs SunOS 4.1.3 (referred to 
as “kontiki”). Each of the project members has a personal computer available to him/her that 
may be used to connect to the other machines. 

Table B.5 lists the operating system software and other support and development tools (and 
the associated version number) used for the GCS project. 


Table B.5: Support and Development Tools 


Software/Tools 

Version 

ACT 

V19921201 #08CTS 

CMS 

V3.4 

Mathematica 

2.2 

Microsoft Word - fBM 

3.0C 

Microsoft Word -Macintosh 

5.1A or 6.0 

Prototype Source Code 

VENUS 19 

Simulator 

GCSSIM2-17 

SunOS 

4.1.3 

TCP/Connect 

VI. 2 

T earn work 

4.1 

VAX FORTRAN* 2 ' 

V5.5-98 

VAX- 11 linker" 3 ' 

V05-13 

VAX/VMS Operating System 

V5.5-2 

VAXnotes 

V2.0 


<a) the compiler (b) includes the loader 


B.3.2 Software Development Tools 

A number of tools are used to aid in the development of the software product, especially with 
respect to the design description and source code. The following sections describe the tools 
which were used for the software development of the GCS project. 

B.3.2.J Teamwork 

For the GCS project, each programmer is required to use the Computer Aided Software 
Engineering (CASE) tool, Team work (ref. B.2), to develop their detailed design description. 
Team work, which is a product of Cadre Technologies, Inc., is a set of software engineering tools 
based on the structured methods of Hatley and DeMarco (ref. B.3). The Team work tools can be 
used to create and edit functional specifications consisting of data flow diagrams, control flow 
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diagrams and event-driven constructs, process specifications, and data dictionary. For the GCS 
project, each programmer had the opportunity to use either of the following Teamwork- 
components to develop their design: 


SA/RT— the baseline structured analysis tool with an extension that allows description of real- 
time systems (ref. B.4), or 

SD — a parallel tool that follows the Ward and Mellor approach to design (ref. B.5). 

Both programmers chose the SA/RT tool to implement their design. The design description 
developed using Teamwork- is required for the design and code reviews. 

B. 3.2.2 FORTRAN 

Although there are a variety of programming languages available for use, requirements for this 
project preclude a programmer from using any language except FORTRAN for the puiposes of 
this project. 

VAX FORTRAN (ref. B.6) is an implementation of full language FORTRAN-77 conforming 
to American National Standard FORTRAN. It includes optional support for programs 
conforming to the previous standard. VAX FORTRAN meets the Federal Information Processing 
Standard Publication requirements by conforming to the ANSI Standard. 

The VAX/VMS FORTRAN compiler creates object code which can then be li nk ed into an 
executable image. The shareable, reentrant compiler operates under the VAX/VMS Operating 
System. It globally optimizes source programs while taking advantage of the floating point and 
character string instruction set and the VMS virtual memory system. 

The primary editor used on the VAX system to edit source code and test cases is the 
VAX/VMS default editor, VAX EDT (ref. B.7). The other editor used for files on the VAX 
system is the VAX Text processing Utility (VAXTPU) (ref. B.8). 

B.3.3 Test Environment 

The following sections describe the tools which were used by the verification analysts to aid 
them in the verification of the implementations. 

B.3.3.1 Mathematica 

Mathematica (ref. B.9) is a general computer software system and language intended for 
mathematical modeling and calculations. It supports numerical, symbolic, and graphical 
computation. It can be used both as an interactive problem solving environment and as a modem 
high-level programming language. Although Mathematica has numerous uses, for the GCS 
project it will be used only as: 

• a numerical and symbolic calculator, 

• a high-level programming language, and 

• a modeling and data analysis environment. 


To independently verify the correctness of sensor, position, and control calculations produced 
during testing, Mathematica will be used to model the computations of each functional unit and 
calculate the expected results. For test cases which generate output that, according to DO-178B, 

B-l 1 



must be compared with independently calculated values, the verification analysts will develop a 
program that compares the test output with the expected values derived from Mathematica 
models. This analysis program will generate a comparison file which can then be evaluated for 
problems. 

B.3.3.2 ACT 

The tool ACT, Analysis of Complexity Tool (ref. B.10), is based on McCabe's Cyclomatic 
Complexity Metric Method (ref. B.l 1). ACT examines the structure of a source code module and 
produces a flow graph based on that structure and identifies all possible paths through the code. 
This tool will be used to aid in structural test case development and structural coverage analysis. 

B.3.3.3 Simulator 

The GCS simulator is an environment developed to allow researchers to study the behavior of 
software and to develop insight into the origin of software errors and the effects of these errors on 
software reliability. The simulator generates input for one or more implementations of the 
guidance and control software and acts upon their output to model the behavior of a planetary 
lander during the terminal descent phase of landing. It also provides access to and analysis of 
important data generated by the implementations so that potential software failures are detected 
and noted for the researcher to further investigate. The simulator is composed of executable, 
input, and output files. The files that compose the simulator are listed in Appendix A under the 
library [GCS.CMS.SIMULATOR.SOURCECODE], 

B.3.3.4 Prototype Source Code 

A prototype implementation of the GCS was developed in conjunction with the GCS 
specification and simulator. The prototype implementation was written in FORTRAN-77, but 
was not written in compliance with any particular software development standards. 

B.3.4 Configuration Management Tools 

For the purposes of the GCS project, DEC/CMS (Code Management System) will be used for 
the configuration management of all software product data. CMS (ref. B.l) is a software library 
system that facilitates the development and maintenance of software systems. Software systems 
are divided into different functional components that are, in turn, organized into sets of one or 
more files. CMS helps manage the files during development, and later during maintenance, by 
storing the files in a project library, tracking changes, and monitoring access to the library. CMS 
also supplies a means of manipulating different combinations of files within a library. The ability 
to formalize these combinations provides a focus for system design and a means of organizing the 
files within a library. Through the use of CMS, programmers will be able to recreate any version 
of their code at any stage during its development; any version of the support documentation can 
also be regenerated. Appendix A lists each CMS library and its contents for all project data that 
is stored electronically. 

B.3.5 Other Tools 

A number of tools will be used by the GCS project participants to interact, distribute 
information electronically, and document activities throughout the project. Although most of the 
communication on the GCS project is done informally through verbal communication or 
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electronic mail, a few tools will be used to document certain project communication, namely 
requests for configuration management services and problem and action reporting. 

B.3.5.1 VAX Notes 

VAX Notes (ref. B.12) is a computer conferencing software product designed to provide users 
with the capability of creating and accessing on-line conferences or meetings. Computer 
conferencing is an electronic messaging technology which lets users conduct meetings with 
people in different geographic locations via computer so that participants can join in a discussion 
from their own desk at a time of their own choice. 

VAX Notes will be used in order to collect data for the purpose of the experiment (not for 
certification). All questions about the GCS specification should be addressed to the system 
analyst. It is especially important to capture the questions that the programmers ask the system 
analyst about the specification and the response from the system analyst. All questions to the 
system analyst should be specific to the GCS specification as opposed to questions about 
implementation specific issues. Additionally, the programmers and verification analysts should 
use VAX Notes when making requests for elements from the configuration manager. 

B.3.5.2 Problem Reporting 

Problem and Action Reports are used to document all information pertaining to problems 
identified in any of the development product (design, source code, or executable object code) and 
Support Documentation Change Reports are used to document modifications to all support 
documents. Copies of these reports are shown in the Software Configuration Management Plan. 

B.3.5.3 File Transfer Protocol 

The File Transfer Protocol (FTP) transfers files between two host systems. There are two 
ways in which FTP is used to retrieve a file from a remote host for the GCS project. The first 
begins when the user initiates a connection to the remote host by entering the command “FTP 
host address”, where a systems is specified in place of “host address”. This requires the user to 
know how to change to the required directory and also how to tell the host system the required 
action. The second way to initiate FTP is by using the TCP/IP connection that is available on the 
Macintoshes; this connection uses a series of pull-down menus and command boxes. 

B.3.6 Qualified Tools 

Since the GCS project is a research effort with limited resources, the qualification of the tools 
used on this project was not attempted. 

B.4 CMS Libraries 

The following lists each CMS library (and its contents) as of 6/4/95. In some libraries, there 
are groups and subgroups; these will be noted under the library column with the format of 
GROUP/SUBGROUP(/SUBGROUP) 
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Elements 


CMS Library 

DISKSHOKIE: [GCS. CMS. ACCOMP SUM] 

DISKSHOKIE: [GCS. CMS.CERT PLAN] cert plan.txt 

DISKSHOKIE: [GCS. CMS.CM PLAN] cm_plan.txt 

DISKSHOKIE: [GCS.CMS.CONFIG INDEX] 

DISKSHOKIE: [GCS. CMS. DES DESCRIP. MERCURY] design.overview_intro 

design.overviewlabels 

design.overview_preface 
design, teamwork 

gcs_design.ps 

mercury_design. 

DISKSHOKIE: [GCS. CMS. DES DESCRIP. PLUTO] design.overview 

design.teamwork 

DISKSHOKIE: [GCS. CMS. DEVSTAND] dev standards.txt 

DISKSHOKIE: [GCS.CMS.EXEC OBJ CODE.MERCUR build_mercury.com 

Y] 

mercury.exe 

DISKSHOKIE: [GCS.CMS.EXEC OBJ CODE.PLUTO] pluto.exe 

p build.com 

DISKSHOKIE: [GCS.CMS.SIMULATOR.SOURCE CODE accuracy.dat 

] 

accuracy, forinc 

accuracy_definitions.for_inc 

alternateaccuracy. dat 

altcheckexternal.for 

alt_check_guidance.for 

alt_check_sensors.for 

alt_compare_ae_cmd.for 

alt_compare_real8.for 

build_create_init_data.com 

build_gcs_sim.com 

build_gcs_sim_nocms.com 

build_rendezvous.com 

build_rendezvous_debug.com 

calculatevalues.for 

checkcp.for 

checkexternal. for 

check_guidance.for 

check_paramenters.for 

checksensors.for 

checkstat.for 

check_timing.for 

cms_fetch.for 

common_record.for_inc 

common_switches.for_inc 

compare_ae_cmd.for 

compare_int2 . for 
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CMS Library 

DISK$HOKIE:[GCS.CMS.SIMULATOR.SOURCE_CODE] 


Elements 


compare_int4 . for 
compare_logl .for 
comp are_mask. for_inc 
compare_real8.for 
completeast.for 
ere. for 

create_init_data.com 

create_init_dat.for 

create_init_data_a.com 

create_init_data_b.com 

doid_defs.for_inc 

do_assigns.com 

gcs_com.for_inc 

gcsintcvt.for 

gcs_list.dat 

gcs_params.for_inc 

gcsrendezvous.mms 

gcs_setup.for 

gcssetup.obj 

gcs_sim.mms 

gcssimrendezvous.for 

gcssimrendezvous.obj 

gcs_sim_switches.dat 

gcs_sim_switches.for_inc 

gcs_who_am_i.for 

gcs_who_am_i.obj 

generateinitialrandomseed.for 
getaccuracydata. for 

get_data.for 

getinitdata.for 

getswitches.for 

global_setup.for 

initialize, for 
initialattitude.for 
initial_contants.dat 
initial_contants_l .dat 
initial_contants_2 . dat 
initial_contants_3 .dat 
initial_contants_4 . dat 
initial_contants_5 .dat 
initial_contants_6 . dat 
initial_contants_7 . dat 
initial_contants_8 . dat 
initial_seed.dat 
init_base_vals.for 
init_timing.for 
integrate, for 
limits.dat 
limits, forinc 
limit check, for 
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DISKSHOKIE: [GCS. CMS. SIMULATOR.USER GUIDE] 
DISKSHOKIE:[GCS.CMS.SOURCE CODE. MERCURY] aeclp.for 

arsp.for 

asp. for 

common, inc 

cp.for 

crcp.for 

excond.inc 

gp-for 

gsp.for 

mercury, for 

mercury_compile.txt 

param.inc 

reclp.for 

tdlrsp.for 

tdsp.for 

tsp.for 
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CMS Library 

Elements 

DISKSHOKIE: [GCS. CMS. SOURCECODE. PLUTO] 

aeclp.for 


arsp.for 

asp. for 

clpsf.for 

constants, for 

cp.for 

crcp.for 

external, for 

gp.for 

gpsf.for 

gsp.for 

guidance state. for 

list of routines.txt 

pluto.for 

reclp.for 

run_parameters.for 

sensoroutput. for 

spsf.for 

tdlrsp.for 

tdsp.for 

tsp.for 

utility. for 

DISK$HOKIE:[GCS. CMS. SPEC] 

spec 2 l.txt 


spec 2 2.txt 

spec_2_3.txt 

DISK$HOKIE:[GCS. CMS. SPEC MODS] 

mod 2 2-1 — > 29.txt 


fm_2_3-l --> 7.txt 

DISK$HOKIE : [GC S . CMS . SQ A_PL AN ] 

sqa_plan.doc 


sqa_plan.ps 

DISK$HOKIE : [GC S . CMS . T RACED AT A] 

reqtrdat.doc 

DISK$HOKIE:[GCS.CMS.VER CASES] 
FRAME 

frame 001 -->009. ex 


frame 001 — > 009. tc 

FUNCTIONAL/DRIVERS 

compare, for 


compare external. for 

compare guidance. for 

comp are_packet. for 

compare_partial external. for 

compare runparam.for 

compare sensor. for 

excp.for 

m clp driver.com 

m gpsf driver.com 

m lnkaeclp.com 

m lnkarsp.com 

m lnkasp.com 

m lnkclp.com 

m lnkcp.com 

m lnkcrcp.com 

m lnkframe.com 
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DISK$HOKIE:[GCS.CMS.VER_CASES] 

FUNCTIONAL/DRIVERS m_lnkgp.com 

m_lnkgpsf.com 

m_lnkgsp.com 

m_lnkreclp.com 

m_lnksp.com 

m_lnktdlrsp.com 

m_lnktdsp.com 

m_lnktsp.com 

mreclpst.l — > .3 

m nm reclp st.Ol --> .03 

m_sp_driver.com 

m_st_driver.com 

m_tc_driver.com 

m_test_ a cclp.for 

m_test_arsp.for 

mtestasp.for 

mtestclp.for 

m_test_cp.for 

m_test_crcp.for 

m_test_frarn e .for 

m_test_gp.for 

m_test_gpsf.for 

mtestgsp.for 

mtestreclp.for 

m_test_sp.for 

mtesttdlrsp.for 

mtesttdsp.for 

mtesttsp.for 

p_buildall.com 

p_clp_driver.com 

p_compare_external . for 

p_compare_guidance.for 

p_compare_runpram. for 

p_compare_sensor.for 

p_ex_cp.for 

p_fordrivers.com 

p_frame_driver.com 

p_gpsf_driver.com 

p_lnkaeclp.com 

p_lnkarsp.com 

p_lnkasp.com 

p_lnkclp.com 
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Elements 


CMS Library 


p_lnkcrcp.com 

p_lnkframe.com 

p_lnkgp.com 

p_lnkgpsf.com 

p_lnkgsp.com 

p_lnkreclp.com 

p_lnksp.com 

p_lnktdlrsp.com 

p_lnktdsp.com 

p_lnktsp.com 

preadex.for 

p_read_tc.for 

p_mn_aeclp.com 

p_mn_arsp.com 

p_mn_asp.com 

p_mn_cp.com 

p_mn_crcp.com 

p_mn_gp.com 

p_mn_gsp.com 

p_mn_reclp.com 

p_mn_tdlrsp . com 

p_mn_tdsp.com 

p_mn_tsp.com 

p_sp_driver.com 

p_tc_driver.com 

ptestaeclp.for 

ptestarsp.for 

ptestasp.for 

p_test_clp.for 

ptestcp.for 

ptestcrcp.for 

p_test_ frame, for 

p_test_gp.for 

p_test_gpsf.for 

p_test_gsp.for 

ptestreclp.for 

ptestsp.for 

ptesttdlrsp.for 

ptesttdsp.for 

p_test_tsp.for 

read ex. for 


p_lnkcp.com 


DISK$HOKIE:[GCS.CMS.VER_CASES] 

FUNCTIONAL/DRIVERS 
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FUNCTIONAL/MODELS 


run_asp.com 

run_asp_pst.com 

run_clp.com 

run_cp.com 

run_crcp.com 

run_gp.com 

run_gpsf.com 

run_gp_pst.com 

run_gsp.com 

run_reclp.com 

exnamelist.inc 
frame, m 

gP-m 

gp_pst7_code.m 

gp_tc.l — > .117 

gsp-m 

input. 

m_aeclp_st. 1 — > .3 
m_asp_st_001 — > 003. m 

m_gp_st.l — > ,9 

m_run_ a eclp_st.01 — > .03 
m_ru n _gp_st.01 — > .11 
mrunstructreclp.0 1 
m_struct_reclp.tc 

m_tdlrsp_st_001 ->011.m 

m_tsp_st_001.m 

namelistl. 

namelist_ex. 

name_list.inc 

reclp.m 

reclp_tc.l — > .68 

reclptc.out 

mn aeclp.Ol -> .57, .010, .1-10, .11-20, .21-30, .31- 

40, .41-47, .48-53, .48-57 

run_crcp.01 ~> ,10, ,1-10 

rungp., .01 ~> .116, .1-10, .11-20, .21-30, .31-40, 
.41-50, .51-60, .61-70, .71-80, .81-90, .91-100, .101- 

110, ,111-114, ,111-116 

run reclp.01 -> .68, .1-10, .11-20, .21-30, .31-40, 

.41-50, .51-60, .61-68 

run_gpsf.01 — > .08 
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CMS Library 

Elements 

DISK$HOKIE:[GCS.CMS.VER CASES] 
FUNCTIONAL/MODELS 

sp.m 


tdlrsp.m 

tdsp.m 

tsp.m 

write exnml.m 

write exnml st7.m 

write nml.m 

write nml st7.m 

FUNCTIONAL/NORMAL 

aeclp_nr_001 — > 012, 054, 055. ex 


aeclp_nr_001 — > 012, 054, 055. tc 

arsp_nr_011 — > 017, 022, 023. ex 

arsp_nr_011 — > 017, 022, 023. tc 

asp_nr_001 — > 007, 016. ex 

asp_nr_001 — > 007, 016.tc 

cp_nr_001 --> 005. ex 

cp_nr_001 — > 005. tc 

crcp_nr_001 — > 006. ex 

crcp_nr_001 ~> 006. tc 

gp nr 001 ~> 008, 053, 102 -> 106.ex 

gp nr 001 ~> 008, 053, 102 -> 106.tc 

gsp_nr_001.ex 

gsp_nr_001.tc 

reclp_nr_001 — > 059, 064 — > 068. ex 

reclp_nr_001 — > 059, 064 — > 068. tc 

tdlrsp_nr_001, 003, 005 — > 021. ex 

tdlrsp_nr_001, 003, 005 — > 021. tc 

tdsp_nr_001 --> 003. ex 

tdsp_nr_001 — > 003. tc 

tsp_nr_001 — > 003, 006, 007. ex 

tsp nr 001 — > 003, 006, 007. tc 

FUNCTIONAL/ROBUSTNESS 

aeclp_ro_013 — > 053, 056, 057. ex 


aeclp_ro_013 — > 053, 056, 057. tc 

arsp_ro_001 — > 010, 018 — > 02 l.ex 

arsp_ro_001 — > 010, 018 --> 021.tc 

asp_ro_008 — > 015, 017 — > 044. ex 

asp_ro_008 — > 015, 017 — > 044.tc 

crcp_ro_007 --> 010. ex 

crcp_ro_007 ~> 010. tc 

gp ro 009 ~> 052, 054 -> 101, 107 -> 117.ex 

gp ro 009 ~> 052, 054 -> 101, 107 -> 117.tc 

gsp_ro_002 -> 009. ex 

gsp_ro_002 -> 009.tc 

reclp_ro_060 — > 063. ex 

reclp_ro_060 — > 063. tc 

tdlrsp_ro_002, 004, 006, 022 — > 028. ex 

tdlrsp_ro_002, 004, 006, 022 — > 028. tc 

tdsp_ro_004 — > 007.ex 

tdsp_ro_004 — > 007.tc 

tsp_ro_004, 005, 008 ~> 01 l.ex 

tsp_ro_004, 005, 008 ~> Oil .tc 


B-21 
























































CMS Library 

Elements 

DISK$HOKIE:[GCS.CMS.VER CASES] 

FUNCTIONAL/STRUCTURAL/MERCURY 

m aeclp st 001— >003. ex 

m aeclp st 001 ~>003.tc 

m arsp st 001, 002. ex 

m arsp st 001, 002. tc 

m asp st 001— >006. ex 

m asp st 001— >006. tc 

m cp st 001. ex 

m cp st 00 l.tc 

m gp st 001 — > 01 l.ex 

m_gp_st_001 — > 01 l.tc 

m reclp st 001 —>003. ex 

m reclp st 001 -> 003.tc 

m tdlrsp st 001 — > 009. ex 

m tdlrsp st 001 — > 009. tc 

m tsp st 00 l.ex 

m tsp st 00 l.tc 

FUNCTIONAL/STRUCTURAL/PLUTO 

aeclp_pst 001, 002. ex 

aeclp_pst 001, 002. tc 

asp_pst 001 ->004. ex 

asp_pst 001 — > 004. tc 

gp_pst 001 -->021. ex 

gp_pst 001 — > 02 l.tc 

reclp_pst 001— >01 l.ex 

reclp_pst 001 — > 01 l.tc 

SUBFRAME 

clp 001— >014. ex 

clp 001->014.tc 

gpsf.com 

gpsf 001 — > 008. ex 

gpsf 001 — > 008. tc 

sp 00 l.ex 

sp 00 l.tc 

TRAJECTORY 

m run traj.com 

m traj.com 

pluto.com 

run mc.com 

run traj.com 

traj.com 

traj atm 001 —> 012. seed 

traj atm ic 001— >012. tc 

traj atm ud 001— >012. tc 

traj td 013 -> 034. seed 

traj td ic 013~>034.tc 

traj_td_ud_013 — > 034. tc 

DISK$HOKIE:[GCS.CMS.VER_PLAN] 

verplan.doc 

DISK$HOKIE:[GCS.CMS.VER_PROC] 

procedures. 

DISK$HOKIE:[GCS.CMS.VER RESULTS.MERCURY] 



DISK$HOKIE:[GCS.CMS.VER_RESULTS. PLUTO] 
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The following is a list of binders and their contents the configuration manager is keeping; the 
“Change Reports” binder is divided into sections. 


Binder Name 

Items 

Problem Reports for Mercury 

PR #1 -31 

Problem Reports for Pluto 

PR #1 -27 

Change Reports: 

Configuration Management Plan 

SDCR #1-6 

Development Standards 

SDCR #1-9 

Spec 

SDCR # 2.2-27 ~> 29, 2.3-1 ~> 7 

Verification Cases 

SDCR #1 -38 

Verification Plan 

SDCR #1 -8 

Verification Procedures 

SDCR #1 
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B.5 Build Files 


Mercury Build File 

The Mercury build file is located in 

diskShokie: [gcs.cms.source_code.mercuryjmercury_compile.txt and is as follows: 
To compile the Mercury source code: 

(generates one object file and one list file) 

fortran/list mercury+tsp+arsp+asp+gsp+tdlrsp+tdsp+gp+aeclp+reclp+crcp+cp 

(generates individual object files and individual list files) 
fortran/list mercury, tsp,arsp,asp,gsp,tdlrsp,tdsp,gp,aeclp,reclp,crcp,cp 


There are eleven) 12) modules for Mercury with each module containing one or 
more subroutines. 

DRIVER 

mercury.for (include files: common.inc, excond.inc, param.inc) 

SP 

tsp.for (include files: common.inc, excond.inc, param.inc) 
arsp.for (include files: common.inc, excond.inc, param.inc) 
asp. for (include files: common.inc, excond.inc, param.inc) 
gsp.for (include files: common.inc, excond.inc, param.inc) 
tdlrsp.for (include files: common.inc, excond.inc, param.inc) 
tdsp.for (include files: common.inc, param.inc) 

GP 

gp.for (include files: common.inc, excond.inc, param.inc) 

CLP 

aeclp.for (include files: common.inc, excond.inc, param.inc) 
reclp.for (include files: common.inc, excond.inc, param.inc) 
crcp.for (include files: common.inc, param.inc) 

CP 

cp.for (include file: common.inc) 
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Pluto Build File 


The Pluto build file is located in disk$hokie:[gcs. cms.source_code.plutoJlist_of_routines.txt 
and is as follows: 


Module 


Brief description 


AECLP.FOR 

ARSP.FOR 

ASP.FOR 

CLPSF.FOR 

CONSTANTS.FOR 

CP.FOR 

CRCP.FOR 

EXTERNAL. FOR 

GP.FOR 

GPSF.FOR 

GSP.FOR 

GUIDANCESTATE.FOR 
PLUTO. FOR 
RECLP.FOR 

RUNPARAMETERS .FOR 

SENSOROUTPUT.FOR 

SPSF.FOR 

TDLRSP.FOR 

TDSP.FOR 

TSP.FOR 

UTILITY. FOR 


Implementation of functional unit AECLP 

Implementation of functional unit ARSP 

Implementation of functional unit ASP 

Contains the control for subframe 3 

Data declarations for constants 

Implementation of functional unit CP 

Implementation of functional unit CRCP 

Data definitions and Common block EXTERNAL 

Implementation of functional unit GP 

Contains the control for subframe 2 

Implementation of functional unit GSP 

Data definitions and Common block GU1DANCE STATE 

The Main program entry 

Implementation of functional unit RECLP 

Data definitions and Common block RUN PARAMETERS 

Data definitions and Common block SENSOR OUTPUT 

Contains the control for subframe 1 

Implementation of functional unit TDLRSP 

Implementation of functional unit TDSP 

Implementation of functional unit TSP 

A collection of utility routines (range checking) 


To Build Required Modules 

AECLP AECLP.FOR, CONSTANTS.FOR, EXTERNAL. FOR, 

GUIDANCESTATE.FOR, RUNPARAMETERS.FOR, 
SENSOR OUTPUT.FOR, UT1L1TY.FOR 

ARSP ARSP.FOR, CONSTANTS.FOR, EXTERN AL.FOR, 

GUIDANCE STATE.FOR, RUN PARAMETERS.FOR, 
SENSOR OUTPUT.FOR, UT1L1TY.FOR 

ASP ASP.FOR, CONSTANTS.FOR, EXTERN AL .FOR, 

GUIDANCE STATE.FOR, RUN PARAMETERS.FOR, 
SENSOR OUTPUT.FOR, UT1L1TY.FOR 

CP CP.FOR, EXTERN AL.FOR, GUIDANCESTATE.FOR, 

RUN PARAMETERS.FOR, SENSOR OUTPUT.FOR 

CRCP CRCP.FOR, CONSTANTS.FOR, EXTERN AL.FOR, 

GU ID AN CESTATE.FOR 


B-25 



GP GP.FOR, CONSTANTS.FOR, EXTERN AL.FOR, 

GUIDANCE STATE.FOR, RUN PARAMETERS.FOR, 
SENSOROUTPUT.FOR, UTILITY.FOR 

GSP GSP.FOR, CONSTANTS.FOR, EXTERN AL .FOR, 

GUIDANCE STATE.FOR, RUN PARAMETERS.FOR, 
SENSOR OUTPUT.FOR, UTILITY.FOR 

RECLP RECLP.FOR, CONSTANTS.FOR, EXTERN AL.FOR, 

GUIDANCE STATE.FOR, RUN PARAMETERS.FOR, 
SENSOR OUTPUT.FOR, UTILITY.FOR 

TDLRSP TDLRSP.FOR, CONSTANTS.FOR, EXTERN AL.FOR, 

GUIDANCE STATE.FOR, RUN PARAMETERS.FOR, 
SENSOROUTPUT.FOR 

TDSP TDSP.FOR, CONSTANTS.FOR, EXTERNAL.FOR, 

GUIDANCE STATE.FOR, SENSOR OUTPUT.FOR, 
UTILITY.FOR 

TSP TSP.FOR, CONSTANTS.FOR, EXTERNAL.FOR, 

GUIDANCE STATE.FOR, RUN PARAMETERS.FOR, 
SENSOR OUTPUT.FOR, UTILITY.FOR 

Subframe 1 ARSP.FOR, ASP.FOR, CP.FOR, GSP.FOR, SPSF.FOR, 

TDSP.FOR, TSP.FOR, CONSTANTS.FOR, EXTERNAL.FOR, 
GUIDANCE STATE.FOR, RUN PARAMETERS.FOR, 
SENSOR OUTPUT.FOR, UTILITY.FOR 

Subframe 2 CP.FOR, GP.FOR, GPSF.FOR, CONSTANTS.FOR, 

EXTERNAL.FOR, GUIDANCE STATE.FOR, 

RUN PARAMETERS.FOR, SENSOR OUTPUT.FOR, 
UTILITY.FOR 

Subframe 3 AECLP.FOR, CLPSF.FOR, CP.FOR, CRCP.FOR, 

RECLP.FOR, CONSTANTS.FOR, EXTERNAL.FOR, 
GUIDANCE STATE.FOR, RUN PARAMETERS.FOR, 
SENSOR OUTPUT.FOR, UTILITY.FOR 

Pluto AECLP.FOR, ARSP.FOR, ASP.FOR, CLPSF.FOR, CP.FOR, 

CRCP.FOR, GP.FOR, GPSF.FOR, GSP.FOR, PLUTO.FOR, 
RECLP.FOR, SPSF.FOR, TDLRSP.FOR, TDSP.FOR, 
TSP.FOR, CONSTANTS.FOR, EXTERNAL.FOR, 
GUIDANCE STATE.FOR, RUN PARAMETERS.FOR, 
SENSOR OUTPUT.FOR, UTILITY.FOR 
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C.l Introduction 


This document contains the records of changes made to the life cycle data placed under configuration 
control in compliance with the Configuration Management Plan for the Guidance and Control Software 
project. Below is a table listing each of the life cycle data items under configuration control. 


Table 1. DO-178B Life Cycle Data for the GCS Project 


Software Life Cycle Data 

Plan for Software Aspects of Certification * 

Software Development Standards 

Software Verification Plan 

Software Configuration Management Plan 

Software Quality Assurance Plan* 

Software Requirements Data 

Design Description for the Mercury Implementation 

Design Description for the Pluto Implementation 

Source Code for the Mercury Implementation 

Source Code for the Pluto Implementation 

Software Verification Cases and Procedures Document 

Software Verification Results for the Mercury Implementation * 

Software Verification Results for the Pluto Implementation* 

Software Configuration Index * 

Test Cases 

Software Accomplishment Summary * 


The * indicates that no revisions were made to that configuration item once it was placed under 
configuration control. The remainder of this document consists of the log of changes made to the 
remaining life cycle data items. Each table gives the configuration management library name for that 
item, the date and action that was taken, the element(s) affected, the requester, and remarks. 

A Support Documentation Change Report that has been logged by the Software Quality Assurance 
(SQA) representative provides that authority necessary to change the support documentation, including 
the plans and procedures documents. A Problem Report that has been logged by the SQA representative 
provides the authority necessary to revise any of the development products (requirements, design, and 
code). Each reservation of a configuration item should correspond to one change report. The change 
report should be noted in the remarks section of each table. 
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C.2 Software Development Standards 


LIBRARY: DISK$HOKIE:[GCS.CMS.DEV_STAND] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 

7/22/93 

create 

element 

dev_standards.txt 

KJH 

in-house Software Development 
Standards 

7/27/93 

reserve 

dev_standards.txt 

KJH 

FM1 

7/28/93 

replace 

dev_standards.txt 

KJH 

finished FM1 

8/31/93 

reserve 

dev standards.txt 

KJH 

FM2 

9/8/93 

replace 

dev_standards.txt 

KJH 

finished FM2 


reserve 

dev standards.txt 

KJH 

FM3 

1/4/94 

unreserve 

dev_standards.txt 

KJH 

UNRESERVED - changed FM3 


reserve 

dev_standards.txt 

KJH 

FM3 

1/6/94 

replace 

dev standards.txt 

KJH 

finished FM3 

5/11/94 

reserve 

dev standards.txt 

KJH 

FM4 

5/12/94 

replace 

dev_standards.txt 

KJH 

finished FM4 

5/17/94 

reserve 

dev_standards.txt 

KJH 

FM5 

5/23/94 

replace 

dev standards.txt 

KJH 

finished FM5 


reserve 

dev_standards.txt 

KJH 

FM6 

5/24/94 

replace 

dev_standards.txt 

KJH 

finished FM6 

5/25/94 

reserve 

dev standards.txt 

KJH 

FM7 


replace 

dev_standards.txt 

KJH 

finished FM7 


reserve 

dev_standards.txt 

KJH 

FM8 


replace 

dev standards.txt 

KJH 

finished FM8 


reserve 

dev_standards.txt 

KJH 

FM9 


replace 

dev_standards.txt 

KJH 

finished FM9 


C.3 Verification Cases and Procedures (document) 


LIBRARY: DISK$HOKIE:[GCS.CMS.VER_PROC] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 

12/8/94 

create element 

procedures. 

cquach 

Verification Procedures and 
Cases 


reserve 

procedures. 

cquach 

FM1 

12/13/94 

replace 

procedures. 

cquach 

finished FM1 
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C.4 Software Verification Plan 


LIBRARY: DISK$HOKIE:[GCS.CMS.VER_PLAN] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 

7/22/93 

create element 

verplan.doc 

SVK 

in-house Software Verification 
Plan 

7/27/93 

reserve 

verplan.doc 

SVK 

FM1 

7/28/93 

replace 

verplan.doc 

SVK 

finished FM1 

7/29/93 

reserve 

verplan.doc 

SVK 

FM2 


replace 

verplan.doc 

SVK 

finished FM2 

8/9/93 

reserve 

verplan.doc 

SVK 

FM3 

8/23/93 

replace 

verplan.doc 

SVK 

finished FM3 

9/10/93 

reserve 

verplan.doc 

DBT 

FM4 

9/22/93 

replace 

verplan.doc 

DBT 

finished FM4 

12/28/93 

reserve 

verplan.doc 

DBT 

FM5 

3/16/94 

replace 

verplan.doc 

DBT 

finished FM5 

3/18/94 

reserve 

verplan.doc 

DBT 

FM6 

5/3/94 

replace 

verplan.doc 

DBT 

finished FM6 

5/31/94 

reserve 

verplan.doc 

CQUACH 

FM7 

8/9/94 

replace 

verplan.doc 

CQUACH 

finished FM7 

12/7/94 

reserve 

verplan.doc 

CQUACH 

FM8 

12/8/94 

replace 

verplan.doc 

CQUACH 

finished FM8 

4/17/95 

fetch (kjh) 

verplan.doc 

kjh 

to review 

4/19/95 

reserve (kjh) 

verplan.doc 

cq 

for SDCR #9 

9/13/95 

replace (kjh) 

verplan.doc 

cq 

finished SDCR#9 


C.5 Software Configuration Management Plan 


LIBRARY: 

DISK$HOKIE : [GC S . CMS . CMP LAN 

I 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 

7/22/93 

create element 

cm_plan.txt 

LJS 

in-house Software Configuration 
Management Plan 

8/31/93 

reserve 

cm_plan.txt 

LJS 

FM1 

9/1/93 

replace 

cm_plan.txt 

LJS 

finished FM1 

5/18/94 

reserve 

cm_plan.txt 

LJS 

FM2 


replace 

cm_plan.txt 

LJS 

finished FM2 


reserve 

cm_plan.txt 

LJS 

FM3 

5/19/94 

replace 

cm_plan.txt 

LJS 

finished FM3 


reserve 

cm_plan.txt 

LJS 

FM4 

5/20/94 

replace 

cm_plan.txt 

LJS 

finished FM4 

12/21/94 

reserve 

cm_plan.txt 

LJS 

FM5 

12/22/94 

replace 

cm_plan.txt 

LJS 

finished FM5 

1/25/95 

reserve 

cm_plan.txt 

Ijs 

FM6 

2/27/95 

replace 

cm_plan.txt 

Ijs 

finished FM 6 

















































































































































































C.6 Software Requirements Data 


LIBRARY: DISK$HOKIE:[GCS.CMS.SPEC] 


DATE ACTION ELEMENT Requester Remarks 

(initials) 

5/17/93 create element spec_2_l.txt KJH in-house Software Requirements Data 

reserve spec_2_l.txt KJH transitional requirements phase 

replace spec_2_l.txt KJH finished mods 

reserve spec_2_l.txt KJH completed mods for Spec 2.1 

create element spec_2_2.txt KJH official version 2.2 

replace spec_2_l.txt KJH completed mods for Spec 2.1 

reserve spec_2_2.txt KJH FM 2.2-1, 2, &3 

replace spec_2_2.txt KJH finished FM 2.2-1, 2, &3 

reserve spec_2_2.txt KJH FM 2.2-4 

replace spec_2_2.txt KJH finished FM 2.2-4 

reserve spec_2_2.txt KJH FM 2.2-5 

replace spec_2_2.txt KJH finished FM 2.2-5 

reserve spec_2_2.txt KJH FM 2.2-6, 7, &8 

replace spec_2_2.txt KJH finished FM 2.2-6, 7, &8 

reserve spec_2_2.txt KJH FM 2.2-9 

5/24/93 replace spec_2_2.txt KJH finished FM 2.2-9 * (1) virtual memory 

error 

fetch spec_2_2.txt had virtual memory error message - 

ensuring replacement of mod 2.2-9 

5/27/93 reserve spec_2_2.txt KJH FM 2.2-10 

6/2/93 replace spec_2_2.txt KJH finished FM 2.2-10 

reserve spec_2_2.txt KJH FM 2.2-11 

replace spec_2_2.txt KJH finished FM 2.2-1 1 

reserve spec_2_2.txt KJH FM 2.2-12 

replace spec_2_2.txt KJH finished FM 2.2-12 

reserve spec_2_2.txt KJH FM 2.2-13 

replace spec_2_2.txt KJH finished FM 2.2-13 

reserve spec_2_2.txt KJH FM 2.2-14 

replace spec_2_2.txt KJH finished FM 2.2-14 

reserve spec_2_2.txt KJH FM 2.2-15 

replace spec_2_2.txt KJH finished FM 2.2-15 

reserve spec_2_2.txt KJH FM 2.2-16 

6/3/93 replace spec_2_2.txt KJH finished FM 2.2-16 

reserve spec_2_2.txt KJH FM 2.2-17 

replace spec_2_2.txt KJH finished FM 2.2-17 

reserve spec_2_2.txt KJH FM 2.2-18 

replace spec_2_2.txt KJH finished FM 2.2-18 

reserve spec_2_2.txt KJH FM 2.2-19 

replace spec_2_2.txt KJH finished FM 2.2-19 

reserve spec_2_2.txt KJH FM 2.2-20 

6/4/93 replace spec_2_2.txt KJH finished FM 2.2-20 
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LIBRARY: DISK$HOKIE:[GCS.CMS.SPEC] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 


reserve 

spec 2 2.txt 

KJH 

FM 2.2-21 


replace 

spec 2 2.txt 

KJH 

finished FM 2.2-21 


reserve 

spec 2 2.txt 

KJH 

FM 2.2-22 


replace 

spec 2 2.txt 

KJH 

finished FM 2.2-22 

6/4/93 

reserve 

spec 2 2.txt 

KJH 

FM 2.2-23 

6/7/93 

replace 

spec 2 2.txt 

KJH 

finished FM 2.2-23 


reserve 

spec 2 2.txt 

KJH 

FM 2.2-24 


replace 

spec 2 2.txt 

KJH 

finished FM 2.2-24 


reserve 

spec 2 2.txt 

KJH 

FM 2.2-25 


replace 

spec 2 2.txt 

KJH 

finished FM 2.2-25 * (2) 
checksum error, virtual 
memory error 


reserve 

spec 2 2.txt 

KJH 

FM 2.2-26 

6/9/93 

replace 

spec 2 2.txt 

KJH 

finished FM 2.2-26 * (3) 
virtual memory error 


fetch 

spec 2 2.txt 


virtual memory error occurred 
when trying to replace with 
spec with mod 2.2-26 

1/6/94 

reserve 

spec 2 2.txt 

KJH 

FM 2.2-27 

1/14/94 

replace 

spec 2 2.txt 

KJH 

finished FM 2.2-27 * (4) 
checksum error, virtual 
memory error 


reserve 

spec 2 2.txt 

KJH 

FM 2.2-28 

2/15/94 

replace 

spec 2 2.txt 

KJH 

finished FM 2.2-28 


reserve 

spec 2 2.txt 

BB 

FM 2.2-29 

3/18/94 

replace 

spec 2 2.txt 

BB 

finished FM 2.2-29 


create element 

spec_2_3.txt 

BB 

Spec Version 2.3 

5/11/94 

reserve 

spec_2_3.txt 

BB 

FM 2.3-1 

5/13/94 

replace 

spec_2_3.txt 

BB 

finished FM 2.3-1 


reserve 

spec_2_3.txt 

BB 

FM 2.3-2 

5/16/94 

unreserve 

spec_2_3.txt 

BB 

font problem when replace 
Spec with FM 2.3-1; need to 
redo mod 


reserve/gen=l 

spec_2_3.txt 

BB 

FM 2.3-1; font problem with 
original mod 

5/18/94 

delete gen 

spec_2_3.txt 

BB 

need to remove so updated 
mod can be entered in library 


replace 

spec_2_3.txt 

BB 

finished FM 2.3-1 


reserve 

spec_2_3.txt 

BB 

FM 2.3-2 

5/19/94 

replace 

spec_2_3.txt 

BB 

finished FM 2.3-2 

5/25/94 

reserve 

spec_2_3.txt 

BB 

FM 2.3-3 

6/15/94 

replace 

spec_2_3.txt 

BB 

finished FM 2.3-3 

8/22/94 

reserve 

spec_2_3.txt 

BB 

FM 2.3-4 

8/25/94 

replace 

spec_2_3.txt 

BB 

finished FM 2.3-4 





























































































































































LIBRARY: DISK$HOKIE:[GCS.CMS.SPEC] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 

9/13/94 

reserve 

spec_2_3.txt 

BB 

FM 2.3-5 

9/23/94 

replace 

spec_2_3.txt 

BB 

finished FM 2.3-5 

11/28/94 

reserve 

spec_2_3.txt 

BB 

FM 2.3-6 

12/22/94 

replace 

spec_2_3.txt 

BB 

finished FM 2.3-6 

1/27/95 

reserve 

spec_2_3.txt 

bb 

FM 2.3-7 

3/15/95 

replace 

spec_2_3.txt 

bb 

finished FM 2.3-7 


C.7 Design Description for the Mercury Implementation 


LIBRARY: DISK$HOKIE:[GCS.CMS.DES_DESCRIP.MERCURY] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 

6/2/93 

create 

element 

mercurydesign. 

MCL 

in-house teamwork design 

7/26/93 

reserve 

mercurydesign. 

MCL 

updating design to most current 
version of Spec 

7/27/93 

replace 

mercury design. 

MCL 

finished mods 


create 

element 

gcs_design.ps 

MCL 

Design Description Document 

12/6/93 

create 

element 

design, overview intro 

ADB 

Mercury Design Description 
Overview (introduction) 



design. overview_preface 

ADB 

Mercury Design Description 
Overview (preface & table of 
contents) 



design, overviewlabels 

ADB 

Mercury Design Description 
Overview (section labels) 

12/10/93 

create 

element 

design.teamwork 

ADB 

teamwork model (with mods thru 
2.2-26) 

12/21/93 

reserve 

design.teamwork 

ADB 

PR#1 

1/18/94 

replace 

design.teamwork 

ADB 

finished PR#1 

1/19/94 

reserve 

design.teamwork 

ADB 

PR#2 

1/28/94 

replace 

design.teamwork 

ADB 

finished PR#2 

1/31/94 

reserve 

design.teamwork 

ADB 

PR#3 

2/15/94 

replace 

design.teamwork 

ADB 

finished PR#3 

2/24/94 

reserve 

design.teamwork 

ADB 

PR#4 

3/14/94 

replace 

design.teamwork 

ADB 

finished PR#4 

3/21/94 

reserve 

design.teamwork 

ADB 

PR#5 

3/25/94 

replace 

design.teamwork 

ADB 

finished PR#5 

3/29/94 

reserve 

design.teamwork 

ADB 

PR#6 

3/31/94 

replace 

design.teamwork 

ADB 

finished PR#6 

4/5/94 

reserve 

design.teamwork 

ADB 

PR#7 

4/6/94 

unreserve 

design.teamwork 

ADB 

UNRESERVE - may have been a 
problem with reservation 


reserve 

design.teamwork 

ADB 

PR#7 (again) 




























































































































































LIBRARY: D1SK$H0KIE:[GCS.CMS.DES_DESCRIP.MERCURY] 

DATE ACTION ELEMENT Requester Remarks 

(initials) 

4/20/94 replace design. teamwork APB finished PR#7 

4/21/94 reserve design, teamwork ADB PR#8 

4/25/94 replace design.teamwork ADB finished PR#8 

reserve design.teamwork ADB PR#9 

4/29/94 replace design.teamwork ADB finished PR#9 

5/3/94 reserve design.teamwork ADB PR#10 

5/9/94 replace design.teamwork ADB finished PR#10 

reserve design.teamwork ADB PR#11 

5/11/94 replace design.teamwork ADB finished PR#1 1 

reserve design.teamwork ADB PR#11 * problem when FTPed 

design - need to replace with good 

_file 

5/12/94 replace design.teamwork ADB finished PR#1 1 

5/13/94 reserve design.teamwork ADB PR#12 

5/16/94 reserve design.overview_intro ADB PR#12 

5/18/94 replace design.teamwork ADB finished PR# 12 

design.overviewintro 

5/20/94 reserve design.teamwork ADB PR#13 

5/31/94 replace design.teamwork ADB finished PR#13 

reserve design.teamwork ADB PR# 14 

6/1/94 replace design.teamwork ADB finished PR#14 

6/20/94 reserve design.teamwork ADB PR#15 

6/23/94 replace design.teamwork ADB finished PR#15 

7/1/94 reserve design.teamwork ADB PR#16 

7/7/94 replace design.teamwork ADB finished PR#16 

reserve design.teamwork ADB PR#17 

7/20/94 replace design.teamwork ADB finished PR#17 

reserve design.teamwork ADB PR#18 

7/27/94 replace design.teamwork ADB finished PR#18 

reserve design.teamwork ADB PR#19 

8/3/94 replace design.teamwork ADB finished PR#19 

reserve design.teamwork ADB PR#20 

8/15/94 replace design.teamwork ADB finished PR#20 

reserve design.teamwork ADB PR#21 

8/18/94 replace design.teamwork ADB finished PR#21 

reserve design.teamwork ADB PR#22 

design, overviewintro ADB 

design. overview_preface ADB 

design.overviewlabels ADB 

8/24/94 replace design.teamwork ADB finished PR#22 

design.overviewintro ADB 

design. overview_preface ADB 

design.overviewlabels ADB 

8/25/94 reserve design.teamwork ADB PR#23 

design.overviewintro ADB 

design. overview_preface ADB 

design.overviewlabels ADB 

8/31/94 replace design.teamwork ADB finished PR#23 

design.overviewintro ADB 
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LIBRARY: DISK$H0K1E:[GCS.CMS.DES_DESCR1P.MERCURY] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 



design. overview_preface 

ADB 




design, overview labels 

ADB 


9/16/94 

reserve 

design.teamwork 

ADB 

PR#24 

9/21/94 

replace 

design.teamwork 

ADB 

finished PR#24 

10/20/94 

reserve 

design.teamwork 

ADB 

PR#25 

12/5/94 

replace 

design.teamwork 

ADB 

finished PR#25 

12/7/94 

reserve 

design.teamwork 

ADB 

PR#26 

12/14/94 

replace 

design.teamwork 

ADB 

finished PR#26 

12/22/94 

reserve 

design.teamwork 

ADB 

PR#27 

1/3/95 

replace 

design.teamwork 

ADB 

finished PR#27 

2/8/95 

reserve 

design.teamwork 

adb 

PR#28 

2/14/95 

replace 

design.teamwork 

adb 

finished PR#28 

3/21/95 

reserve 

design.teamwork 

adb 

PR #30 

3/24/95 

replace 

design.teamwork 

adb 

finished PR #30 

4/28/95 

reserve 

design.teamwork 

adb 

PR#31 

5/1/95 

reserve 

design, overview labels 

adb 

PR#31 

5/5/95 

replace 

design, overview labels 

adb 

finished PR#3 1 



design.teamwork 




C.8 Design Description for the Pluto Implementation 


LIBRARY: DISK$HOKIE:[GCS.CMS.DES_DESCRIP.PLUTO] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 

8/31/93 

create element 

design.teamwork 

PSC 

in-house teamwork model 
from RTI version 


reserve 

design.teamwork 

PSC 

updating teamwork model to 
Spec version 2.2 


replace 

design.teamwork 

PSC 

finished mod 


create element 

design, overview 

PSC 

Pluto Design Description 
Overview 

11/1/93 

reserve 

design.teamwork 

PSC 

PR#1 

1/18/94 

replace 

design.teamwork 

PSC 

finished PR#1 

1/25/94 

reserve 

design.teamwork 

PSC 

PR#2 

2/15/94 

replace 

design.teamwork 

PSC 

finished PR#2 

4/14/94 

reserve 

design.teamwork 

RKA 

PR#3 

4/20/94 

replace 

design.teamwork 

RKA 

finished PR#3 


reserve 

design.teamwork 

RKA 

PR#4 

5/2/94 

replace 

design.teamwork 

RKA 

finished PR#4 


reserve 

design.teamwork 

RKA 

PR#5 


replace 

design.teamwork 

RKA 

finished PR#5 


reserve 

design.teamwork 

RKA 

PR#6 





































































































































































LIBRARY: DISK$HOKIE:[GCS.CMS.DES DESCRIP.PLUTO] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 

5/5/94 

replace 

design.teamwork 

RKA 

finished PR#6 


reserve 

design.teamwork 

RKA 

PR#7 

5/9/94 

replace 

design.teamwork 

RKA 

finished PR#7 


reserve 

design.teamwork 

RKA 

PR#8 

5/11/94 

replace 

design.teamwork 

RKA 

finished PR#8 *checksum 
error, insufficient virtual 
memory, error replacing 


reserve 

design.teamwork 

RKA 

PR#9 *checksum error, bad 
block address 


unreserve 

design.teamwork 

RKA 

checksum error when reserving 


reserve 

design.teamwork 

RKA 

PR#9 


replace 

design.teamwork 

RKA 

finished PR#9 


reserve 

design.teamwork 

RKA 

PR# 10 

6/2/94 

replace 

design.teamwork 

RKA 

finished PR# 10 


reserve 

design.teamwork 

RKA 

PR# 11 

6/9/94 

replace 

design.teamwork 

RKA 

finished PR#1 1 *checksum 
error, insufficient virtual 
memory, error replacing 


reserve 

design.teamwork 

RKA 

PR# 12 

6/21/94 

replace 

design.teamwork 

RKA 

finished PR# 12 *checksum 
error, insufficient virtual 
memory, error replacing 


reserve 

design.teamwork 

RKA 

PR#13 *bad block address 


unreserve 

design.teamwork 

RKA 

bad block address (0 blocks 
reserved) 


reserve 

design.teamwork 

RKA 

PR# 13 

6/28/94 

replace 

design.teamwork 

RKA 

finished PR#13 *checksum 
error, insufficient virtual 
memory, error replacing 


reserve 

design.teamwork 

RKA 

PR#14 *bad block address 


unreserve 

design.teamwork 

RKA 

bad block address (0 blocks 
reserved) 


reserve 

design.teamwork 

RKA 

PR#14 *bad block address 


unreserve 

design.teamwork 

RKA 

unreserve - bad block address 


delete gen=15 

design.teamwork 

RKA 

corrupt file 


reserve 

design.teamwork 

RKA 

PR# 13 - will replace file with 
uncorrupted file 


replace 

design.teamwork 

RKA 

finished PR#13 *checksum 
error, insufficient virtual 
memory, error replacing 


reserve 

design.teamwork 

RKA 

PR#14 *bad block address 


unreserve 

design.teamwork 

RKA 

unreserve - bad block address 


reserve 

design.teamwork 

RKA 

PR#14 *bad block address 

6/29/94 

replace 

design.teamwork 

RKA 

finished PR# 14 

7/20/94 

reserve 

design.teamwork 

RKA 

PR# 15 


unreserve 

design.teamwork 

RKA 

UNRESERVE - wrong model 
replaced 
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LIBRARY: DISK$H0K1E:[GCS.CMS.DES_DESCR1P.PLUT0] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 


delete gen=16 

design.teamwork 

RKA 

wrong model replaced 

7/21/94 

reserve 

design.teamwork 

RKA 

PR#14 (again) 


replace 

design.teamwork 

RKA 

finished PR# 14 


reserve 

design.teamwork 

RKA 

PR# 15 


replace 

design.teamwork 

RKA 

finished PR# 15 

7/21/94 

reserve 

design.teamwork 

RKA 

PR# 16 

7/22/94 

replace 

design.teamwork 

RKA 

finished PR# 16 


reserve 

design.teamwork 

RKA 

PR# 17 

7/29/94 

remark 



due to power outage this entire 
library had to be backed up; 
some of the create dates 
changed to today 


replace 

design.teamwork 

RKA 

finished PR# 17 


reserve 

design.teamwork 

RKA 

PR# 18 

8/2/94 

replace 

design.teamwork 

RKA 

finished PR# 18 

8/11/94 

reserve 

design.teamwork 

RKA 

PR# 19 



design, overview 

RKA 

PR# 19 

8/26/94 

replace 

design, overview 

RKA 

finished PR#19 - converted 
from WordPerfect to Microsoft 
Word file 



design.teamwork 

RKA 

finished PR# 19 

9/16/94 

reserve 

design.teamwork 

RKA 

PR#20 


replace 

design.teamwork 

RKA 

finished PR#20 

11/18/94 

reserve 

design.teamwork 

PEM 

PR#21 



design, overview 

PEM 

PR#21 

11/23/94 

replace 

design, overview 

PEM 

finished PR#2 1 



design.teamwork 

PEM 

finished PR#2 1 

1 1/28/94 

reserve 

design.teamwork 

PEM 

PR#22 

11/30/94 

replace 

design.teamwork 

PEM 

finished PR#22 

3/16/95 

reserve 

design.teamwork 

pem 

PR#27 

3/21/95 

replace 

design.teamwork 

pem 

finished PR #27 
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C.9 Source Code for the Mercury Implementation 


LIBRARY: D1SK$H0K1E:[GCS.CMS.SQURCE_C0DE.MERCURY] 


DATE 

ACTION 

ELEMENT 

Requester 

(initials) 

Remarks 

9/23/94 

create element 

*.for 

ADB 

create Mercury source code 
files 



*.inc 

ADB 

create Mercury include files 



*.txt 

ADB 

create file for instructions to 
complies Mercury source code 

10/20/94 

reserve 

*.for 

ADB 

PR#25 



*.inc 

ADB 

PR#25 

12/5/94 

replace 

*.for 

ADB 

finished PR#25 



*.inc 

ADB 

finished PR#25 

12/7/94 

reserve 

*.for 

ADB 

PR#26 



*.inc 

ADB 

PR#26 

12/14/94 

replace 

*.for 

ADB 

finished PR#26 



*.inc 

ADB 

finished PR#26 


fetch 

* * 

DBT 

testing code 

12/22/94 

reserve 

cp.for 

ADB 

PR#27 

12/29/94 

replace (kjh) 

cp.for 

ADB 

finished PR#27 


fetch (kjh) 

cp.for 

DBT 

for Mercury testing 

2/8/95 

reserve 

gp.for 

ADB 

PR#28 

2/14/95 

replace 

gp.for 

adb 

finished PR#28 


fetch 

gp.for 

dbt 

Mercury testing 

3/8/95 

fetch (kjh) 

reclp.for 

kjh 

to aid in review of structural 
test cases 

3/21/95 

reserve 

asp. for 

adb 

PR #30 



gp.for 



3/24/95 

replace 

asp. for 

adb 

finished PR #30 



gp.for 




fetch 

asp. for 

dbt 

for testing of code 



gp.for 



7/20/95 

fetch (kjh) 

*.for 

kjh 

to count number of source 
lines 



*.inc 
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C.10 Source Code for the Pluto Implementation 


LIBRARY: DISK$HOKIE:[GCS.CMS.SOURCE_CODE.PLUTO] 

DATE ACTION ELEMENT Requester Remarks 

(initials) 

9/26/94 create element *.* RKA create Pluto source code files 

11/23/94 reserve *lbr PEM PR#22 

11/28/94 unreserve *.for PEM wrong element requested — 

wanted design 

11/30/94 reserve *.for PEM PR#23 

12/5/94 replace *.for PEM finished PR#23 

12/21/94 fetch *.for cquach testing Pluto code 

1/10/95 reserve *.for pem PR#24 

1/13/95 replace *.for pem finished PR#24 

reserve cp.for pem PR#25 

fetch arsp.for cquach Pluto testing 

constants, for 

gp-for 

tdlrsp.for 

tsp.for 

replace cp.for pem finished PR#25 

1/17/95 fetch cp.for cquach testing Pluto code 

1/19/95 delete gen=4 cp.for wrong version of element 

replaced 

reserve cp.for pem PR#25 

replace cp.for pem finished PR#25 — replacing 

with correct version of 
element 

fetch cp.for cquach for Pluto testing 

2/14/95 reserve clpsf.for pem PR#26 

pluto.for 

2/15/95 replace clpsf.for pem finished PR#26 

pluto.for 

3/6/95 fetch pluto.for cq trajectory testing 

clpsf.for 

3/15/95 reserve asp. for pem PR #27 

gp-for 

3/21/95 replace asp. for pem finished PR #27 

gp-for 

4/6/95 fetch (kjh) *.for cq for functional unit testing 

reserve (kjh) *.for cq PR#28 

replace (kjh) *.for cq finished PR#28 

fetch (kjh) *.for cq for functional unit testing 
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C.ll Test Cases 


including models, drivers, and expected results 

LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 

DATE ACTION NAME Requester Remarks 

(initials) 

8/4/94 create group functional group containing functional 

unit test cases 

subframe group containing subframe test 

cases 

frame group containing frame test 

cases 

normal subgroup of functional group 

containing normal range test 

cases 

robustness subgroup of functional group 

containing robustness test 

cases 

structural subgroup of functional group 

for structural test cases 
(implementation specific) 

models subgroup of functional group 

containing math models 

drivers subgroup of functional group 

containing drivers 

insert group drivers -> functional subgroup of functional unit 

group 

models -> functional subgroup of functional unit 

group 

normal -> functional subgroup of functional unit 

group 

robustness -> functional subgroup of functional unit 

group 

structural -> functional subgroup of functional unit 

group 

create group pluto subgroup of structural group 

for Pluto test cases 

mercury subgroup of structural group 

for Mercury test cases 

insert group mercury -> structural subgroup of structural group 

pluto -> structural subgroup of structural group 

create element aeclp nr OOl.ex, .tc DBT AECLP functional unit test 

cases NR: 001 ->012; 

RO : 013 -> 036 

insert element *nr*.* -> normal normal range test case for 

AECLP functional unit 
*ro*.* - Robustness robustness test case for 

AECLP functional unit 

8/15/94 create element aeclp_nr_039.ex, .tc DBT AECLP functional unit test 

case NR: 039 -> 047; 

RO: 037,038 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 


DATE 

ACTION 

NAME 

Requester 

(initials) 

Remarks 



crcp_nr_001.ex, .tc 


CRCP functional unit test case 
NR: 001 ->006; 

RO: 007 ->010 


insert element 

*nr*.* -> normal 


normal range test case for 
AECLP/CRCP functional unit 



*ro*.* -> robustness 


robustness test case for 
AECLP/CRCP functional unit 

8/29/94 

reserve 

aeclp*.ex 

DBT 

FM 1 



crcp*.ex 


FM 2 


replace 

aeclp*.ex 

DBT 

finished FM 1 * error 
replacing aeclp nr 039. ex thru 
aeclp nr 47. ex 



crcp*.ex 


finished FM 2 


unreserve 

aeclp_nr_039 -> 047. ex 

dbt 

should have been robustness 
test cases 

8/30/94 

remove element 

aeclp_nr_039 -> 047.ex, 
.tc from normal 

DBT 

should have been robustness 
test case 


delete element 

aeclp_nr_039 -> 
047.ex,.tc 

DBT 

should have been robustness 
test case 


create element 

aeclp_ro_039 -> 053.ex, 
.tc 

DBT 

AECLP functional unit test 
case 


insert element 

aeclp*ro*.* 
-> robustness 


robustness test case for 
AECLP functional unit 

8/31/94 

create element 

j-* * 

DBT 

RECLP functional unit test 
case NR: 1-59, 64-68; RO: 
60-63 


insert element 

r*nr*.* -> normal 


normal range test case for 
RECLP functional unit 



r*ro*.* -> robustness 


robustness test case for 
RECLP functional unit 

9/6/94 

create element 

gp*.* 

DBT 

GP functional unit test cases 
NR:1 - 8, 53, 102- 106; RO: 9 
- 52, 54 - 101,107 - 114 


insert element 

gp nr*.* -> normal 


normal range test case for GP 
functional unit 


gpro*.* -> robustness robustness test case for GP 

functional unit 


9/12/94 

reserve 

gp*-* 

DBT 

FM 3 

9/13/94 

create element 

aeclp*.* 

DBT 

functional unit test cases NR: 
54, 55; RO: 56,57 


insert element a*nr*.* -> normal normal range test case for 

AECLP functional unit 



robustness test case for 
AECLP functional unit 
finished FM 3 


9/13/94 


replace 


DBT 


12/2/94 


DBT 


FM 4 
FM 5 


reserve 

































































































LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 


DATE 

ACTION 

NAME 

Requester 

(initials) 

Remarks 



replace 



gP • 


aeclp*.* 


reclp*.* 


crcp*.* 


gpsf*.* 


clp*.* 


gpsf*.* -> subframe 


clp*.* -> subframe 


gp_r°_*.* 


cp_nr_*.* 


* m 


insert element 


remove element 


delete element 


insert element 


12/14/94 



tdsp_*.* 


tsp_*.* 


frame_*.* 


S p_* * 


common, inc 


cp.for 


*.inc 


*_nr_*.* -> normal 


* rQ ^ "f* 


_imm*.* -> subframe 


-> subframe 


frame_*.* -> frame 


cp.for -> models 


*.inc -> models 


*.m -> models 


aeclp_*_*.* 



DBT 


CQUACH 



FM 6 


FM 7 


finished FM 4 


finished FM 5 


FM 4 — replace with wrong 
file 


FM 5 — replace with wrong 
file 


finished FM 4 


finished FM 5 


finished FM 6 


finished FM 7 


GP subframe test case 


CLP subframe test case 


subframe test case for GP 


subframe test case for CLP 


GP functional unit test case 


CP functional unit test case 


mathematica model 


mathematica model 


ARSP functional unit test case 


ASP functional unit test case 


GSP functional unit test case 


TDLRSP functional unit test 
case 


TDSP functional unit test case 


TSP functional unit test case 


frame test case 


subframe test case 


models 


mathematica model 


mathematica model 


normal range test cases 


robustness test cases 


element should not have been 
created 


element should not have been 
created 


subframe test case 


frame test case 


mathematica model 


mathematica model 


mathematica model 


testing Mercury code 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 

DATE ACTION NAME Requester Remarks 

(initials) 



crcp * *.* 

12/16/94 fetch clp_0*.* DBT testing Mercury code 


gpsf_0*.* 

sp_0*.* 

asp_*_*.* 

arsp_*_*.* 

tdlrsp_*_*.* 

tdsp_*_*.* 

gsp "f* ”!• "I" 

tsp_*_*.* 

12/19/94 fetch cp_*.* DBT testing Mercury code 

create element m_*.* DBT Mercury drivers 

compar*.* drivers 

12/19/94 create element excp.for DBT drivers 

read_*.* 

run*.* 

insert element m_*.* -> drivers drivers for Mercury 

compar*.* -> drivers drivers 

ex_cp.for -> drivers 
read_*.* _. drivers 
run *.* -> drivers 

12/21/94 fetch aeclp_*.* cquach testing Pluto code 



gpsf_*.* 

g S p_* * 

reclp*.* 

S p_* * 

tdlrsp_*.* 

tdsp*.* 

tsp_*.* 

12/22/94 reserve cp.for cquach FM8 

cp*.* 

12/28/94 replace (kjh) cp.for cquach finished FM8 

cp *.* 


C-18 



















































































LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 

DATE ACTION NAME Requester Remarks 

(initials) 

fetch (kjh) cp_*.* dbt for Mercury testing (new cp 

test cases) 

cp.for cquach for Pluto testing 

cp *.* 

reserve (kjh) asp.m cquach FM9 

asp_*.* 

12/29/94 replace (kjh) asp_*.* cquach finished FM9 

fetch (kjh) asp *.* cquach for Pluto testing 

create group pluto_drivers temp driver storage for Pluto 

(kjh) 

1/3/95 create element p_*.* cquach drivers for Pluto 

insert element p_*.* -> drivers Pluto drivers 

fetch p_*.* cquach testing Pluto code 

1/4/95 fetch (cquach) gp_nr_001.ex for Pluto testing 

gp_nr_001.tc 

unreserve asp.m reserved by mistake 

1/11/95 reserve cp.for cquach FM10 

cp *.* 

1/12/95 replace cp*.* cquach finished FM10 

fetch cp_*.* cquach for Pluto testing 

cp_*.ex dbt Mercury testing 

1/30/95 fetch *.m cquach Pluto testing 

2/3/95 fetch G: frame dbt Mercury testing 

G: subframe 

2/7/95 reserve p_ex_cp.for cquach FM 1 1 

2/8/95 reserve clp_0 11.* cquach FM 12 

gpsf_*.* 

2/10/95 unreserve p_ex_cp.for cquach should not be implementation 

specific 

reserve excp.for FM 1 1 

replace ex cp.for finished FM 1 1 

2/13/95 replace clp_0 11.* cquach finished FM 12 

gpsf_*.* 

2/13/95 fetch ex_cp.for dbt Mercury testing 

clpOll.tc 

gpsf_*.* 

reserve m_clp_driver.com dbt FM 13 

m_gpsf_driver.com 
m_lnkframe .com 
m_lnkgpsf.com 
m_lnksp.com 
m_sp_driver.com 

2/14/95 fetch clp_011.ex dbt Mercury testing 


C-19 





































































































































LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 


DATE ACTION NAME 



Requester 

(initials) 


Remarks 


2/23/95 


sp_001.* 


gpsf_*.* 


clp_*.* 


trajectory 


* tm j *f ! 


pluto.com 


run_mc.com 


*traj* -> trajectory 


pluto.com -> trajectory 


run_mc.com -> 
traj ectory 


m_c lp_dri ver. com 


m_gpsf_driver.com 


m_lnkframe .com 


m_lnkgpsf.com 


m_lnksp.com 


m_sp_driver.com 


frame_*.* 


p_test_framc. for 


frame_*.* 


p_tcst_framc.for 


frame_*.* 


mtcstframc.for 


mtestframe.for -> 
drivers 


asp_pst_*.* 


tdlrsp_pst_*.* 


*_pst.com 


*pst.com -> drivers 


reclp_pst_*.* 


*_pst_*.* -> Pluto 


m_*_st_0%%.* 


m _*_st.* 


m*struct_reclp.* 


m_*_st_0%%.* -> 
Mercury 


m _*_st_0%%.m 


m_*_st. * -> Mercury 


m_*st*.m -> Mercury 


m*struct_reclp.* -> 
Mercury 


gp.m 


cquach Pluto testing 



cquach 


cquach 


group containing trajectory test 


cquach trajectory test cases 



Mercury testing 


driver for Mercury 


Mercury driver 


structural test cases 


test drivers 


test case drivers 


Pluto structural test cases 


Pluto structural test cases 


Mercury structural test cases 


Mercury Mathematica models 


Mercury structural test cases 


placed in wrong group by 
mistake 


Mercury Mathematica models 



cquach FM15 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 

DATE ACTION NAME Requester Remarks 

(initials) 



frame_*.* 

2/24/95 replace gp.m cquach finished FM15 



2/24/95 replace gpsf_*.* cquach finished FM15 

frame_*.* 

fetch gp.m cquach retesting 



frame_*.* 

reserve m_gp_st_*.* dbt FM 16 

create element *aeclp*.* dbt Mathematica models 



*reclp*.* 

reserve mrungpst*.* dbt FM 16 

replace m_gp_st_*.* dbt finished FM 16 

mrungpst*.* 

create element input. dbt Mathematica model 

namelistl. 
namelis_ex. 

insert element aeclp tc.* -> models Mathematica models 

crcp tc.* -> models 
gp tc.* -> models 
reclp tc.* -> models 
run_aeclp. %%,%-%%, 

%%-%% -> models 

run_crcp.%% -> models 
run_gp. %%,%-%%, 

%%-%% -> models 

runrec lp . %%,%-%%, 

%%-%% -> models 

create element m_st_driver.com dbt Mercury driver 

insert element m_st_driver.com -> Mercury driver 

drivers 

reserve mrunaeclpst.* dbt FM 17 

m_i'un_r £ ' c lp_st. * 

fetch m_aeclp_st_*.* dbt Mercury testing 

m_arsp_st_*.* 
m_asp_st_*.%% 
m_gp_st_*.* 
m_reclp_st_*.* 
m_tdlrsp_st_*.* 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 

DATE ACTION NAME Requester Remarks 

(initials) 

m_tsp_st_*.* 

gp_nr_*.* 

gp_r°_*.* 

gpsf_*.* 

frame_*.* 

insert element input. -> models Mathematica model 

namelist 1. -> models 
namelistex. -> models 

replace m_run_aeclp_st.* dbt finished FM 17 

m_r un _reclp_st. * 

create element gp_pst_*.* cquach Pluto structural test cases 

aeclp_pst_*.* 

run_gp_pst.com Pluto test case drivers 

run_aeclp_pst.com 

insert element *_pst_*.* -> pluto Pluto structural test cases 

*pst.com -> drivers Pluto test case drivers 

2/27/95 reserve gp_*.tc dbt FM 18 

unreserve *pst*.* not needed 

2/27/95 reserve gp_nr_*.ex dbt FM 18 

gp_ro_*.ex 

gpsf_*.* 

m_gp_st*.* 

namelistl. 

namelistex. 

fetch (kjh) traj td *.* cq for evaluation of test cases 

expected results 

2/28/95 fetch (kjh) gp_nr_*.* cq to rerun GP functional unit test 

cases (SDCR 18) 

replace (kjh) gp_nr_*.ex dbt for SDCR 18 

gp_ro_*.ex 
gpsf_*.* 
m_gp_st*.* 
namelistex. 
namelistl. 

3/1/95 fetch (kjh) gp_nr_*.* cq to rerun GP functional unit test 

cases (SDCR 18) 

gp_ro_*.* 

gpsf_*.* cq to run subframe test cases 

(SDCR 18) 

frame *.* cq to run frame test cases (SDCR 

m 

gp.m cq copy of revised gp model 

reserve (kjh) m gp st*.* dbt SDCR 19 

replace (kjh) m gp st*.* dbt for SDCR 19 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 


DATE 

ACTION 

NAME 

Requester 

(initials) 

Remarks 


3/2/95 


3/3/95 




fetch (kjh) 



unreserve (kjh) 


reserve (kjh) 


replace (kjh) 


create element 
(kjh) 


fetch (kjh) 



reserve (kjh) 


create element 
(kjh) 



replace (kjh) 


fetch 



reserve 


replace 


fetch 


reserve 


replace 



gpsf_*.* 


m_gp_st*.* 


m_gp_st.* 


gpsf_*.* 


gpsf_*.* 


run_gpsf.* 


spOOL* 


gpsf_*.* 


clp_*.* 


frame_*.* 


frame_*.* 


traj_atm_*.* 


traj_td_*.* 


traj.com 


run_traj .com 


gp_pst_*.* 


*.m 


m_*.com 


gp_pst_*.* 


traj.com 


run_traj .com 


traj_atm_*.* 


traj_td_*.* 


m_aeclp_st*.* 


m_gp_st*.* 


m_reclp_st*.* 


m_asp_st*.* 


m_st_driver.com 


m_st_driver.com 


m_st_driver.com 


m_tdlrsp_st*.* 


m_tdlrsp_st*.* 



to rerun GP functional unit test 
cases (SDCR 18) 


to run subframe test cases 


for GP structural tests 


wrong file reserved — should 
have been test case files, not 
models 


SDCR 20 


for SDCR 20 


Mathematica models for GP 
subframe 


to rerun GP subframe test 
cases (SDCR 20) 


for subframe testing 


for GP subframe testing 


for Control Law Processing 
subframe testing 


for frame testing 


for frame testing 


for trajectory testing of 
Mercury 



SDCR 21 


models used to generate Pluto 
structural test cases 


file for running Mercury 
trajectory test cases 


for SDCR 21 


trajectory testing 


trajectory testing 




structural testing of Mercury 
(**wrong remark entered in 
CMS**) 



SDCR 22 


finished SDCR 22 


structural testing of Mercury 


SDCR 23 


finished SDCR 23 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 

DATE ACTION NAME Requester Remarks 

(initials) 

3/10/95 create element *run*.* dbt Mathematica drivers for 

Mercury 

*st*.ex dbt structural expected values for 

Mercury 

*st*.tc dbt structural test cases for 

Mercury 

insert element *run*.* -> drivers dbt Mathematica drivers for 

Mercury 

m_gp_st.* -> drivers 

remove element m_gp_st.* -> drivers placed in wrong group 

create element m_tdlrsp_st_*.m dbt Mathematica models for 

Mercury 

insert element m_*.m -> models Mathematica models for 

Mercury 

remove element *run*.* -> drivers placed in wrong group 

insert element m_gp_st_%%%.%% -> Mercury structural test cases 

Mercury and expected values 

rn run *.* -> models Mathematica models for 

Mercury 

3/13/95 insert element *.m -> models Mathematica models 

run_gpsf.%% -> models dbt Mathematica models 

m*traj. com -> trajectory dbt trajectory test cases 

3/14/95 create element m cp st *.* dbt Mercury structural test cases 

and expected values 

insert element m cp st *.* -> Mercury Mercury structural test cases 

and expected values 

3/15/95 reserve gp.m cq SDCR#24 

asp.m 
frame. m 
asp_nr_*.* 
asp_ro_*.* 
gp_nr_*.* 
gp_ro_*.* 

S p_* * 

gpsf_*.* 

frame_*.* 

maspst*.* dbt SDCR#25 

m_gp_st_*.* 

reclp_nr_068.* dbt SDCR 27 

3/16/95 create element m reclp st *.* dbt Mercury structural test cases 

m_reclp_st.* dbt Mercury Mathematica driver 

m _run_reclp_st. * 

insert element m reclp st *.* -> Mercury structural test cases 

Mercury 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 

DATE ACTION NAME Requester Remarks 

(initials) 

mreclpst.* -> drivers Mercury Mathematica driver 

m_run_reclp_st.* -> 
drivers 

remove element m reclp st.* -> drivers placed in wrong group 

m run reclp st.* -> 
drivers 

replace reclp_nr_068.* dbt finished SDCR 27 

3/23/95 replace gp.m cq finished SDCR #24 

asp.m 
frame. m 
asp_nr_*.* 
asp_ro_*.* 
gp_nr_*.* 
gp_ro_*.* 
sp_*.* 
gpsf_*.* 
frame_*.* 

3/24/95 fetch gp_nr_*.* dbt Mercury trajectory testing 

gp_ro_*.* 

asp_nr_*.* 

3/24/95 fetch asp_ro_*.* dbt Mercury trajectory testing 

gpsf_*.* 

sp_*.* 

frame_*.* 

traj_atm_*.* 

traj_td_*.* 

3/27/95 create element gp_ro_117.* dbt GP functional unit test case 

insert element gp_ro_117.* -> robustness functional unit test 

robustness cases 

fetch gp_ro_117.* for Mercury testing 

3/28/95 create element m_asp_st_*.tc dbt Mercury structural test cases 

m_asp_st_*.ex 

insert element m asp st *.* -> Mercury structural test cases 

Mercury 

create element *.seed cq trajectory test expected values 

insert element *.seed -> trajectory trajectory test expected values 

fetch m_aeclp*.ex, .tc dbt Mercury structural testing 

m_asp*.ex, .tc 
m_cp*.ex, .tc 
m_gp*.ex, .tc 
m_reclp*.ex, .tc 
m_tdlrsp*.ex, .tc 

*.seed dbt Mercury trajectory testing 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 



4/5/95 


4/5/95 


ACTION NAME Requester Remarks 

(initials) 

replace (kjh) m_asp_st_*.ex, .tc dbt finished SDCR #25 

m_gp_st_*.e x , .tc 

reserve (kjh) run_traj.com cq SDCR #31 

tdlrsp.m cq SDCR #28 

tdlrsp_nr_*.* cq 


S P_001.* 

frame_*.ex, .tc 


replace (kjh) 

run traj.com 

cq 

for SDCR #31 

reserve (kjh) 

tdlrsp_pst_*.ex, .tc 

cq 

SDCR #30 

replace (kjh) 

m asp st *.m 

dbt 

finished SDCR #25 

create (kjh) 

m asp st *.m 

dbt 

Mercury structural test case — 
models 

reserve (kjh) 

m_tdlrsp_st_*.* 

dbt 

SDCR #29 

unreserve (kjh) 

tdlrsp_pst_*.ex,.tc 

cq 

no modifications were needed 
(see SDCR #30) 

reserve (kjh) 

asp_pst_*.tc,.ex 

cq 

for SDCR #26 

fetch (kjh) 

asp.m 

cq 

for SDCR #26 — to regenerate 
test cases 

reserve (kjh) 

gp_pst_*.tc,.ex 

cq 

for SDCR #26 

fetch (kjh) 

gp.m 

cq 

for SDCR #26 - for 
regeneration of test cases 


asp.m 

dbt 

to verify structural test cases 


gP-m 

aeclp.m 

reclp.m 

cp.for 

m_asp_st_*.* 

m_aeclp_st*.* 

m_gp_st*.* 

m_reclp_st*.* 

m_cp_st*.* 


reserve (kjh) 

tdlrsp_ro_*.tc,.ex 

cq 

for SDCR #28 

replace (kjh) 

tdlrsp.m 

cq 

for SDCR #28 


tdlrsp_nr_*.* 

tdlrsp_ro_*.* 

S P_001.* 


frame *.* 


fetch (kjh) 

tdlrsp.m 

fetch (kjh) 

m_tdlrsp_st_*.* 

replace (kjh) 

gp_pst_*.tc,.ex 


asp_pst_*.tc,.ex 


gp_pst_018.* 

gp_pst_018.* 

m_tdlrsp_st_*.* 


dbt 

to verify structural test cases 

dbt 

to verify structural test cases 

cq 

for SDCR #26 


for SDCR #26 
for SDCR #26 
for SDCR #29 




4/6/95 


reserve (kjh) 
replace (kjh) 
replace (kjh) 
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_cq_ 

_cq_ 

dbt 























































































































LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 


DATE 

ACTION 

NAME 

Requester 

(initials) 

Remarks 



unreserve (kjh) 


gp_nr_053.exl 


tdlrsp_nr_006.* 


remove element tdlrsp_nr_006.* from 
(kjh) normal 


gp_nr_053.exl from 
normal 


aeclp_nr_*.* 


aeclp_ro_*.* 


arsp_nr_*.* 


fetch (kjh) 


arsp_ro_*.* 


asp_nr_*.* 


asp_ro_*.* 


cp_nr_*.* 


crcp_nr_*.* 


crcp_ro_*.* 


gp_nr_*.* 


gp_ro_*.* 


gsp_nr_*.* 


gsp_ro_*.* 


reclp_nr_*.* 


reclpro*.* 


tdlrsp_nr_*.* 


tdlrspro*.* 


tdsp_nr_*.* 


tdspro*.* 


tsp_nr_*.* 


tspro*.* 


comp are_external . for 


comp are_guidance. for 


compare_sensor.for 


excp.for 


readtc.for 


readex.for 


p_tc_driver.com 


p_test_*.for 


p_lnk*.com 


q cn nr * * 


asp_nr_ . 


asp_ro_*.* 


arsp_nr_*.* 


arsp_ro_*.* 


gsp_nr_*.* 


gsp_ro_*.* 


tsp_nr_*.* 


kjh nonexistent test case 


kjh not a valid test case 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 

DATE ACTION NAME Requester Remarks 

(initials) 

tsp_ro_*.* 

tdsp_nr_*.* 

tdspro*.* 

tdlrsp_nr_*.* 

tdlrsp_ro_*.* 

compare_runparam.for 

create element commons, for inc cq utility fde for requirements- 

(kjh) based testing 

struct, forinc 

4/6/95 fetch (kjh) *.for_inc cq for functional unit testing 

clp_*.* dbt for subframe testing 

sp_001.* 
gpsf_gpsf_*.* 

4/7/95 fetch (kjh) frame_*.* dbt for frame testing 

traj *.* dbt for trajectory testing 

gp_nr_*.* cq for functional unit testing 

gp_ro_*.* 
aeclp_nr_*.* 
aeclp_ro_*.* 
reclp_nr_*.* 
reclpro*.* 
crcp_nr_*.* 
crcp_ro_*.* 
cp_nr_*.* 
p_lnk*.com 
p_test_*.for 

p_lnk*.com cq to check link fdes for debug 

statements 

reserve (kjh) p_lnkcrcp.com cq forSDCR#32 

p_lnkreclp.com 
p_lnkcp.com 

fetch (kjh) m aeclp st*.* dbt for Mercury structural testing 

m_asp_st_*.* 
m_reclp_st*.* 
m_gp_st*.* 
m_tdlrsp_st*.* 

replace (kjh) p_lnk*.com cq for SDCR #32 

fetch (kjh) p_lnkcrcp.com cq for Pluto functional unit testing 

p_lnkreclp.com 
p_lnkcp.com 

sp_00 1 . * for Pluto subframe testing 

gpsf_*.* 

clp_*.* 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 


DATE ACTION NAME 



Requester 

(initials) 


Remarks 


ptestsp.for 


P_test_gpsf.for 


ptestelp.for 


p_test_frame. for 


p_sp_driver.com 


p_clp_driver.com 


p_gpsf_driver.com 


p_lnksp.com 


p_lnkgpsf.com 


p_lnkclp.com 


p_lnkframe.com 


excp.for 


p_test_gpsf.for 


p_frame_driver.com 


p_gpsf_driver.com 


p_gpsf_driver.com 


p_clp_driver.com 


p_gpsf_driver.com 


p_clp_driver.com 


p_gpsf_driver.com 


p_clp_driver.com 


traj_*.* 


traj .com 


run_traj.com 


asp_pst_*.* 


m_asp_st_004, 005, 
006.* 


m_run_traj .com 


m_asp_st_004, 005, 
006.* 


m_run_traj .com 


m_run_traj. c o m 


m_asp_st_*.* 


asp_pst_002.* 


asp_pst_002.* 


asp_pst_*.* 


gp_pst_*.* 


aeclp_pst_*.* 


reclp_pst_*.* 


for Pluto frame testing 


for Pluto subframe testing 



for Pluto frame testing 


for Pluto subframe testing 



for Pluto frame testing 


for Pluto subframe testing 


for pluto frame testing 


for Pluto subframe testing 


for SDCR #33 






for Pluto trajectory testing 


to verify that these test cases 
are necessary given changes to 
Pluto ASP module 


for SDCR #34 


for SDCR #35 


for SDCR #34 


for SDCR #35 


to rerun Mercury trajectory 
tests 


to rerun Mercury structural test 
cases for ASP 


for SDCR #36 


for SDCR #36 


for Pluto structural testing 
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LIBRARY: DISK$HOKIE:[GCS.CMS.VER_CASES] 


DATE 

ACTION 

NAME 

Requester 

(initials) 

Remarks 



p lnkasp.com 





p_lnkgp.com 





p lnkaeclp.com 





p lnkreclp.com 





ptestasp.for 





p_test_gp.for 





ptestaeclp.for 





ptestreclp.for 





compare external. for 





comp are_guidance . for 





compare runparam.for 





compare sensor.for 





excp.for 





read tc.for 





p tc driver.com 





read ex. for 




delete element 
(kjh) 

gp_nr_053.exl 

cq 

for SDCR #37 



tdlrsp_nr_006.ex,.tc 




remove element 
(kjh) 

tdlrsp_pst *.* from 
pluto 

kjh 

test cases no longer needed 


delete element 
(kjh) 

tdlrsp_pst_*.* 

cq 

for SDCR #37 

4/14/95 

copy element 
(kjh) 

run traj.com to 
p run traj.com 

cq 

nee to make this fde Pluto 
specific 



traj.com to p traj.com 




reserve (kjh) 

p run traj.com 

cq 

for SDCR #38 


replace (kjh) 

p run traj.com 

cq 

for SDCR #38 


create element 
(kjh) 

p_build.com 

cq 

for Pluto trajectory testing 



m build.com 

dbt 

for Mercury trajectory testing 
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Appendix D: Software Quality Assurance Records for the Guidance 
and Control Software Project 

Author: Kelly J. Hayhurst, NASA Langley Research Center 


This document was produced as part of Guidance and Control Software (GCS) Project conducted at 
NASA Langley Research Center. Although some of the requirements for the Guidance and Control 
Software application were derived from the NASA Viking Mission to Mars, this document does not 
contain data from an actual NASA mission. 
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D.l Introduction 


As described in the Radio Technical Commission for Aeronautics RTCA/DO-178B 
guidelines, "Software Considerations in Airborne Systems and Equipment Certification," (ref. 
D.l) the Software Quality Assurance (SQA) process provides evidence that the software life 
cycle processes satisfy their objectives and that the resultant software conforms to its 
requirements. The primary means that SQA provides this evidence is by assuring that the 
software life cycle processes are performed in compliance with the approved software plans and 
standards. The Software Quality Assurance Records for the GCS project consist of the reports 
from reviews that are held during each of the development processes and the status logs for all of 
the change reports for the project’s life cycle data. 

An SQA report was produced at the closure of each development process for each of the two 
GCS implementations. Mercury and Pluto. The basic form of all the reports is an introduction 
followed by the overview of the review sessions and a listing of any problem reports that are 
issued. Each report documents the SQA approval for a particular stage of the implementation's 
development and contains an acceptance statement signed by the SQA representative as part of 
the report. 

For each of the GCS implementations, the following reports are included in this document: 
Preliminary Design Review Report, Design Review Report, and Test Completion Report for 
Integration. There is also a Test Readiness Review Report for Requirements-based Testing that 
was conducted at the start of the integration process. Because only one set of requirements-based 
test cases was developed for the project, the review of those cases was not implementation 
specific. 

The status logs for all of the change reports for the project’s life cycle data were handwritten 
and have been copied and appended to this document. 
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D.2 Software Quality Assurance Records for Mercury 


Software Quality Assurance Records 

Record Type: Preliminary Design Review Report Closure Date: 5/31/94 

GCS Implementation: Mercury 

Relevant Configuration Items: 

Design Description for Mercury 

Software Verification Procedures (for Design Reviews), Design Review Checklist, Requirements 
Traceability Matrix 

Notes: 

Overview Meeting held on 12/2/93 

6 Review Sessions held 12/7/93-12/10/93 

Participants: Kelly Hayhurst (SQA representative/Moderator) 

Debbie Taylor (Verification Analyst/Recorder, Inspector) 

Andy Boney (Programmer/Reader, Inspector) 

Bernice Becher (System Analyst/Inspector) 

The design description has many substantial problems — and they were recorded on 13 Problem Reports: 
PRs # 1-13. 

Due to the significant problems identified in these review sessions, another design review should be 
scheduled to re-inspect the entire design description. 

Further, PR #14 was also issued as the result of a change to the GCS specification (Spec mod 2.3-2) and 
was completed and approved. 

All problem reports (#1 - 13) were completed and approved by the SQA representative. This report only 
signifies the closure of what will now be called the preliminary design review phase. (That is, this report 
does not signify the completion of the design process.) The design is now ready for the next Design 
Review sessions. 

Problem Reports: #1 - 13, #14 

SQA representative signature Original Signed by Kelly Hayhurst 
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Software Quality Assurance Records 


Record Type: Design Review Report Closure Date: 8/30/94 

GCS Implementation: Mercury 

Relevant Configuration Items: 

Design Description for Mercury 

Software Verification Procedures (for Design Reviews), Design Review Checklist, Requirements 
Traceability Matrix 

Notes: 

Overview Meeting held on 6/3/94 
2 Review Sessions held 6/29/94 

Participants: Kelly Hayhurst (SQA representative/Moderator) 

Debbie Taylor (Verification Analyst/Recorder, Inspector) 

Andy Boney (Programmer/Reader, Inspector) 

Bernice Becher (System Analyst/lnspector) 

An informal review of the design was conducted by the System Analyst prior to the review sessions. 

The System Analyst initiated Problem Report #15 to address some problems in the high-level structure 
charts in the design, because she thought the review of the design would be easier if the corrections were 
made prior to the actual inspection sessions. PR #15 was completed and approved prior to the review 
sessions. 

A number of problems were identified in the review sessions — and they were recorded on 7 Problem 
Reports: PRs # 16 - 22. 

Further, PR #23 was also issued as the result of a change to the GCS specification (Spec mod 2.3-4) and 
was completed and approved. 

All problem reports (#16 - 22) were completed and approved by the SQA representative. 

This report signifies the closure of the design process for Mercury. 

The design is now ready for the code process. 

Problem Reports: #15, #16 - 22, #23 

SQA representative signature Original Signed by Kelly Hayhurst 
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Software Quality Assurance Records 


Record Type: Code Review Report Closure Date: 

12/10/94 

GCS Implementation: Mercury 

Relevant Configuration Items: 

Source Code for Mercury 

Software Verification Procedures (for Code Reviews), Code Review Checklist, Requirements 
Traceability Matrix 

Notes: 

Overview Meeting held on 10/4/94 
2 Review Sessions held 10/19/94 

Participants: Kelly Hayhurst (SQA representative/Moderator) 

Debbie Taylor (Verification Analyst/Recorder, Inspector) 

Andy Boney (Programmer/Reader, Inspector) 

Bernice Becher (System Analyst/lnspector) 

During the development of the source code, the programmer identified a problem in the design 
description. The programmer initiated Problem Report #24. PR #24 was completed and approved by 
the SQA representative prior to submitting the code for review. 

A number of problems were identified in the review sessions — and they were recorded on 2 Problem 
Reports: PRs # 25 - 26. 

All problem reports (#25-26) were completed and approved by the SQA representative. 

This report signifies the closure of the code process for Mercury. 

The source code is now ready for the integration process. 


Problem Reports: #24, #25 - 26 

SQA representative signature Original Signed by Kelly Hayhurst 
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Software Quality Assurance Records 


Record Type: Test Completion Report for the Integration Process Closure Date: 4/15/95 

GCS Implementation: Mercury 
Relevant Configuration Items: 

Requirements-based Test Cases and Requirements Traceability Matrix 

Multiple Condition/Decision Coverage Tables for all Mercury Source Code, Structure diagrams of 
the source code. Structure-based Test Cases 

Software Verification Procedures 

Notes: 

The requirements-based testing started on December 14, 1994. 

In response to Spec mod # 2.3-6, the programmer initiated PR #27. PR #27 was completed and 
approved. 

PR #28 was issued as a result of functional unit testing. 

PR #29 was initiated by the verification analyst, but determined to not be a problem. 

PR #30 was initiated and completed in response to Spec mod #2.3-7 

Trajectory testing (with complete regression testing of all requirements-based test cases) was 
completed on 4/7/95. 

Several informal reviews of the structure-based test cases were held. Final review and approval of 
Structure-based test cases was 4/6/95 

Participants: Kelly Hayhurst (SQA representative) 

Debbie Taylor (Verification Analyst) 

During structure -based testing, a problem was found in some of the test cases and SDCR #34 was issued 
and completed to correct those test cases. 

No problems were found in the Mercury code during structure -based testing. 

All Integration was completed 4/10/95. 

All problem reports (#27-30) were completed and approved by the SQA representative. 

This report signifies the closure of the integration process for Mercury. 

Problem Reports: #27 - #30 

SQA representative signature Original Signed by Kelly Hayhurst 
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D.3 Software Quality Assurance Records for Pluto 


Software Quality Assurance Records 

Record Type: Preliminary Design Review Report Closure Date: 6/29/94 

GCS Implementation: Pluto 

Relevant Configuration Items: 

Design Description for Pluto 

Software Verification Procedures (for Design Reviews), Design Review Checklist, Requirements 
Traceability Matrix 

Notes: 

Overview Meeting held on 8/26/93 

9 Review Sessions held 9/16/93 - 10/15/93 

Participants: Kelly Hayhurst (SQA representative/Moderator) 

Rob Angellatta (Verification Analyst/Recorder, Inspector) 

Paul Carter (Programmer/Reader, Inspector) 

Bernice Becher (System Analyst/Inspector) 

The Software Development Standards state that the design should be “balanced” within the team work 
tool prior to submitting the design for review. However, the design as presented for the review was not 
balanced. The review team decided to proceed with the review. 

Many substantial problems were identified in the design description — and they were recorded on 13 
Problem Reports: PRs#l-13. 

Due to the significant problems identified in these review sessions, another design review should be 
scheduled to re-inspect the entire design description. 

Further, PR #14 was also issued as the result of a change to the GCS specification (Spec mod 2.3-2) and 
was completed and approved. The design is now ready for the next Design Review sessions. 

This report only signifies the closure of what will now be called the preliminary design review phase. 

All problem reports (#1 - 14) were completed and approved by the SQA representative. 

The design description is now ready to proceed to the next Design Review sessions. 

Problem Reports: #1 - 13, #14 

SQA representative signature Original Signed by Kelly Hayhurst 


D-8 












Software Quality Assurance Records 


Record Type: Design Review Report Closure Date: 8/26/94 

GCS Implementation: Pluto 

Relevant Configuration Items: 

Design Description for Pluto 

Software Verification Procedures (for Design Reviews), Design Review Checklist, Requirements 
Traceability Matrix 

Notes: 

2 Review Sessions held 7/13/94 

Participants: Kelly Hayhurst (SQA representative/Moderator) 

Patrick Quach (Verification Analyst/Recorder, Inspector) 

Rob Angellatta (Programmer/Reader, Inspector) 

Bernice Becher (System Analyst/Inspector) 

Some problems were identified in the review sessions — and they were recorded on 5 Problem Reports: 
PRs # 15 - 19. 

All problem reports (#15 - 19) were completed and approved by the SQA representative. 

This report signifies the closure of the design process for Pluto. 

The design is now ready for the code process. 


Problem Reports: #15 - 19 

SQA representative signature Original Signed by Kelly Hayhurst 
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Software Quality Assurance Records 


Record Type: Code Review Report Closure Date: 12/5/94 

GCS Implementation: Pluto 

Relevant Configuration Items: 

Source Code for Pluto 

Software Verification Procedures (for Code Reviews), Code Review Checklist, Requirements 
Traceability Matrix 

Notes: 

Overview Meeting held on 10/26/94 
2 Review Sessions held 11/16/94 

Participants: Kelly Hayhurst (SQA representative/Moderator) 

Patrick Quach (Verification Analyst/Recorder, Inspector) 

Philip Morris (Programmer/Reader, Inspector) 

Bernice Becher (System Analyst/lnspector) 

During the development of the source code, Spec mod #2.3-4 was issued. The programmer initiated PR 
#20 in response to the requirements change. PR #20 was completed and approved prior to submitting 
the code for review. 


A number of problems were identified in the review sessions — and they were recorded on 3 Problem 
Reports: PRs#21-23. 

All problem reports (#20 - 23) were completed and approved by the SQA representative. 

This report signifies the closure of the code process for Pluto. 

The Pluto source code is now ready for the integration process. 


Problem Reports: #20, #21-23 

SQA representative signature Original Signed by Kelly Hayhurst 
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Software Quality Assurance Records 


Record Type: Test Completion Report for the Integration Process Closure Date: 4/15/95 

GCS Implementation: Pluto 
Relevant Configuration Items: 

Requirements-based Test Cases and Requirements Traceability Matrix 

Multiple Condition/Decision Coverage Tables for all Mercury Source Code, Structure diagrams of 
the source code. Structure-based Test Cases 

Software Verification Procedures (for Testing) 

Notes: 

The requirements-based testing started on January 4, 1994. 

PRs #24 and #25 were issued as a result of functional unit testing. 

PR #26 was issued as a result of frame testing. 

PR #27 was issued as a result of trajectory testing 

Trajectory testing (with complete regression testing of all requirements-based test cases) was 
completed on 4/7/95. 

Final review and approval of Structure-based test cases for Pluto was 4/10/95 
Participants: Kelly Hayhurst (SQA representative) 

Patrick Quach (Verification Analyst) 

No problems were found in the Pluto code during structure -based testing. 

All Integration testing was completed 4/1 1/95. 

All problem reports (#24 - 27) were completed and approved by the SQA representative. 

This report signifies the closure of the integration process for Pluto. 


Problem Reports: #24 - 27 

SQA representative signature Original Signed by Kelly Hayhurst 
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D.4 Software Quality Assurance Record for Test Readiness Review for 
Requirements-based Testing 

Software Quality Assurance Records 

Record Type: Test Readiness Review for Requirements-based Testing Closure Date: 12/14/95 

GCS Implementation: N/A 
Relevant Configuration Items: 

Requirements-based Test Cases and Requirements Traceability Matrix 
Software Verification Procedures (for Testing) 

Notes: 

Review of the Requirements-based test cases was held 12/14/94 
Participants: Kelly Hayhurst (SQA representative) 

Patrick Quach (Verification Analyst) 

Debbie Taylor (Verification Analyst) 

The Requirements Traceability Matrix was completed — all requirements identified in the matrix 
were covered by at least one test case. 

No problems were found in the requirements-based test cases. 

This report signifies that the requirements for requirements-based testing as described in the Software 
Verification Plan have been satisfied. The executable object code for each of the GCS implementations 
can now be tested. 


Problem Reports: None 

SQA representative signature Original Signed by Kelly Hayhurst 
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D.5 Status Logs for Problem Reports 


Problem Reports Assigned for Action 

Implementation: Mercury 


PR# 

Date 

Assigned 

Assigned to: 

Date Received 
(by Project 
Leader) 

Date 

Approved 
(by SQA) 

# of 
Action 
Reports 

Comments 

1 

12/20/93 

Andy Boney — Prog 

1/4/94 

1.14.94 

1 

To SQA 1/6/94 

2 

1/18/94 

Andy Boney — Prog 

1/24/94 

1/27/94 

1 

To SQA 1/24/94 

3 

1/27/94 

Andy Boney — Prog 

2/9/94 

2/15/94 

1 

To SQA 2/1 1/94 

4 

2/15/94 

Andy Boney — Prog 

3/7/94 

3/8/94 

1 


5 

3/17/94 

Andy Boney — Prog 

3/24/94 

3/24/94 

1 

signed by kjh for SQA 

6 

3/24/94 

Andy Boney — Prog 

3/29/94 

3/30/94 

1 

signed by kjh for SQA 

7 

3/30/94 

Andy Boney — Prog 

4/20/94 

4/20/94 

1 

GP 

8 

4/20/94 

Andy Boney — Prog 

4/22/94 

4/22/94 

1 

AECLP 

9 

4/22/94 

Andy Boney — Prog 

4/26/94 

4/28/94 

1 

RECLP 

10 

4/28/94 

Andy Boney — Prog 

5/6/94 

5/6/94 

1 

CP 

11 

5/6/94 

Andy Boney — Prog 

5/12/94 

5/12/94 

1 

Data Dictionary 

12 

5/12/94 

Andy Boney — Prog 

5/16/94 

5/17/94 

1 

Misc. typos, etc. 

13 

5/19/94 

Andy Boney — Prog 

5/31/94 

5/31/94 

1 

PATs 

14 

5/31/94 

Andy Boney — Prog 

5/31/94 

5/31/94 

1 

Scheduling - Spec 
Mod 2.3-2 

15 

6/17/94 

Andy Boney — Prog 

6/22/94 

6/22/94 

1 

High Level/P ATs 

16 

6/30/94 

Andy Boney — Prog 

7/6/94 

7/7/94 

1 

High Level/P ATs 

17 

7/7/94 

Andy Boney — Prog 

7/20/94 

7/20/94 

1 

SP 

18 

7/20/94 

Andy Boney — Prog 


7/25/94 

1 

GP *signed off by 
Bernice Becher 

19 

7/26/94 

Andy Boney — Prog 

8/3/94 

8/3/94 

1 

RECLP, AECLP, CLP 

20 

8/3/94 

Andy Boney — Prog 

8/12/94 

8/15/94 

1 

CP 

21 

8/15/94 

Andy Boney — Prog 

8/18/94 

8/18/94 

1 

Limit Checking 

22 

8/18/94 

Andy Boney — Prog 

8/23/94 

8/23/94 

1 

Intro & Misc. 

23 

8/25/94 

Andy Boney — Prog 

8/29/94 

8/30/94 

1 

Spec Mod 

24 

9/15/94 

Andy Boney — Prog 

9/19/94 

9/19/94 

1 

Minor updates to 
design due to coding 

















































































































































































Problem Reports Assigned for Action 

Implementation: Mercury 

PR# Date Assigned to: Date Date # of Comments 

Assigned Received (by Approved Action 

Project (by SQA) Reports 

Leader) 

25 10/20/94 Andy Boney - Prog 12/2/94 12/2/94 2 Misc. stuff from the 

Code Review 

26 12/6/94 Andy Boney — Prog. 12/10/94 12/10/94 1 Misc. problems found 

from Code Review 

27 12/22/94 Andy Boney - Prog 12/23/94 12/27/94 1 Spec Mod 2.3-6 

28 2/7/95 Andy Boney - Prog 2/13/95 2/13/95 1 GP problems 

29 3/14/95 Andy Boney - Prog 3/15/95 3/15/95 0 Thought there was 

dead code in RECLP — 

not true 

30 3/17/95 Andy Boney - Prog 3/23/95 3/24/95 1 Spec Mod 2.3-7 


31 4/28/95 Andy Boney - Prog 5/2/95 5/2/95 1 Misc/minor clean up 

Technical editing 
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Problem Reports Assigned for Action 


Implementation: Pluto 


PR# 

Date 

Assigned 

Assigned to: 

Date 

Received (by 
Project 
Leader) 

Date 

Approved 
(by SQA) 

# of 
Action 
Reports 

Comments 

1.0 

10/28/93 

Paul Carter — Prog 

12/21/93 

1/14/94 

1 

To SQA 1/11/94 

2.0 

1/21/94 

Paul Carter — Prog 

2/1 1/94 

2/15/94 

1 

To SQA 2/1 1/94 

3.0 

4/11/94 

Rob Angellatta — Prog 

4/19/94 

4/20/94 

1 

To SQA 4/19/94 

4.0 

4/20/94 

Rob Angellatta — Prog 

4/29/94 

5/2/94 

1 

ARSP 

5.0 

5/2/94 

Rob Angellatta — Prog 

5/2/94 

5/2/94 

1 

ASP 

6.0 

5/2/94 

Rob Angellatta — Prog 

5/4/94 

5/4/94 

1 

GSP 

7.0 

5/4/94 

Rob Angellatta — Prog 

5/6/94 

5/6/94 

1 

TDLRSP 

8.0 

5/6/94 

Rob Angellatta — Prog 

5/9/94 

5/10/94 

1 

TDSP 

9.0 

5/10/94 

Rob Angellatta — Prog 

5/11/94 

5/11/94 

1 

RECLP 

10.0 

5/11/94 

Rob Angellatta — Prog 

5/31/94 

6/2/94 

1 

AECLP 

11.0 

6/2/94 

Rob Angellatta — Prog 

6/9/94 

6/9/94 

1 

CP 

12.0 

6/9/94 

Rob Angellatta — Prog 

6/20/94 

6/20/94 

1 

GP 

13.0 

6/21/94 

Rob Angellatta — Prog 

6/27/94 

6/28/94 

1 

High Level Diagrams 

14.0 

6/28/94 

Rob Angellatta — Prog 

6/29/94 

6/29/94 

1 

Spec Mod 2.3-2 

15.0 

7/18/94 

Rob Angellatta — Prog 

7/21/94 

7/21/94 

1 

SP, P-Specs 1.2, 1.3, 
1.5, 1.7 

16.0 

7/21/94 

Rob Angellatta — Prog 

7/22/94 

7/22/94 

1 

CLP, P-Specs 1.8, 3.2, 
3.3, 3.4 

17.0 

7/22/94 

Rob Angellatta — Prog 

7.28.94 

7.29.94 

1 

DFDs, Data Dictionary 

18.0 

7/29/94 

Rob Angellatta — Prog 

8/2/94 

8/2/94 

1 

GP 

19.0 

8/11/94 

Rob Angellatta — Prog 

8/24/94 

8/26/94 

1 

Intro & Syntax clean 
up 

20.0 

9/16/94 

Rob Angellatta — Prog 

9/16/94 

9/16/94 

1 

Spec Mod 2.3-4 

21.0 

11/17/94 

Philip Morris — Prog 

1 1/22/94 

1 1/22/94 

1 

Design Corrections / 
Code Review 

22.0 

1 1/22/94 

Philip Morris — Prog 

11/29/94 

11/29/94 

1 

Design Corrections / 
Code Review 

23.0 

11/29/94 

Philip Morris — Prog 

12/5/94 

12/5/94 

1 

Code Corrections / 
Code Review 

24.0 

1/10/95 

Philip Morris — Prog 

1/11/95 

1/13/95 

1 

Unit Test Problems 

25.0 

1/13/95 

Philip Morris — Prog 

1/13/95 

1/13/95 

1 

CP 
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Problem Reports Assigned for Action 

Implementation: Pluto 

PR# Date Assigned to: Date Date # of Comments 

Assigned Received (by Approved Action 

Project (by SQA) Reports 

Leader) 

26.0 2/13/95 Philip Morris - Prog 2/15/95 2/15/95 1 CLP subframe 

problem 

27.0 3/14/95 Philip Morris - Prog 3/21/95 3/21/95 1 ASP - numerical 

accuracy in mean calc. 

28.0 4/6/95 Patrick Quach - Ver. 4/6/95 4/6/95 1 compiling problem 

Analyst 
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D.6 Status Logs for Support Documentation Change Reports 

Support Documentation Change Reports Assigned for Action 


Configuration Item: Software Development Standards 


SDCR # 

Date 

Assigned 

Assigned to: 

Date Received 
(by Project 
Leader 

Date 

Approved 
(by SQA) 

Comments 

1 

7/27/93 

Kelly Hayhurst 

7/27/93 


Original report not available 
from Dr. Liceaga 

2 

8/30/93 

Kelly Hayhurst 

8/30/93 

8/30/93 

okayed by G. Finelli — 
acting SQA 

3 

8/30/93 

Kelly Hayhurst 



canceled by kjh 

3 

1/3/94 

Kelly Hayhurst 

1/4/94 

1/5/94 


4 

5/6/94 

Kelly Hayhurst 

5/12/94 

5/12/94 

Code Standards 

5 

5/16/94 

Kelly Hayhurst 

5/23/94 

5/23/94 

change from 3 to 2 
implementations 

6 

5/23/94 

Kelly Hayhurst 

5/24/94 

5/24/94 

Formal Modifications 

7 

5/25/94 

Kelly Hayhurst 

5/25/94 

5/25/94 

Design Standards 

8 

5/25/94 

Kelly Hayhurst 

5/25/94 

5/25/94 

Bolding of spec 

9 

5/25/94 

Kelly Hayhurst 

5/25/94 

5/25/94 

More code standards 
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Support Documentation Change Reports Assigned for Action 


Configuration Item: Software Configuration Management Plan 


SDCR# Date Assigned to: Date Received Date Comments 

Assigned (by Project Approved 

Leader (by SQA) 

1 8/31/93 Laura Smith 8/31/93 9/1/93 

2 5/18/94 Laura Smith 5/18/94 5/18/94 change from 3 to 2 

implementations 

3 5/18/94 Laura Smith 5/19/94 5/19/94 change from transitional 

code phase to just code 

phase 

4 5/19/94 Laura Smith 5/19/94 5/20/94 Misc/minor changes to 

process 

5 12/19/94 Laura Smith 12/22/94 12/22/94 Problem Reporting 


procedures 

6 1/25/95 Laura Smith 1/26/95 2/24/95 Misc/technical editing 
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Support Documentation Change Reports Assigned for Action 


Configuration Item: Software Verification Plan 


SDCR # 

Date 

Assigned 

Assigned to: 

Date Received 
(by Project 
Leader 

Date 

Approved 
(by SQA) 

Comments 

1 

7/27/93 

Sandra Koppen 

7/27/93 

7/27/93 

change to design review 
checklist 

2 

7/29/93 

Sandra Koppen 

7/29/93 

7/29/93 

change to design review 
checklist 

3 

8/6/93 

Debbie Taylor 

8/6/93 

8/6/93 

moderator duties — okayed 
by G. Finelli — acting SQA 

4 

9/9/93 

Debbie Taylor 

9/21/93 

9/21/93 

change in SQA role — 
okayed by G. Finelli 

5 

12/28/93 

Debbie Taylor 

1/7/94 

3/14/94 

sent to SQA 3/4/94 

6 

3/17/94 

Debbie Taylor, Patrick 
Qua eh 

5/2/94 

5/2/94 

changes to review 
procedures 

7 

5/31/94 

Patrick Quach 

8/8/94 

8/8/94 

add table of contents, revise 
testing activities 

8 

12/6/94 

Debbie Taylor, Patrick 
Quach 

12/8/94 

12/8/94 

make consistent with Cases 
& Procedures 

9 

4/19/95 

Patrick Quach 

5/25/95 

9/13/95 

Technical editing 
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Support Documentation Change Reports Assigned for Action 


Configuration Item: Software Verification Cases & Procedures 
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Support Documentation Change Reports Assigned for Action 


Configuration Item: Software Verification Cases (test cases, models, drivers, etc.) 


SDCR # 

Date 

Assigned 

Assigned to: 

Date Received 
(by Project 
Leader 

Date 

Approved 
(by SQA) 

Comments 

1 

8/25/94 

Debbie Taylor 

8/30/94 

8/30/94 

AECLP expected value files 

2 

8/25/94 

Debbie Taylor 

8/30/94 

8/30/94 

CROP expected value files 

3 

9/12/94 

Debbie Taylor 

9/15/94 

9/15/94 

changing GP test cases & 
expected results 

4 

9/21/94 

Debbie Taylor 

12/2/94 

12/2/94 

Spec Mod 2.3-4 GP 

5 

9/21/94 

Debbie Taylor 

12/2/94 

12/2/94 

Spec Mod 2.3-4 AECLP 

6 

9/21/94 

Debbie Taylor 

12/2/94 

12/2/94 

Spec Mod 2.3-4 RECLP 

7 

9/21/94 

Debbie Taylor 

12/2/94 

12/2/94 

Spec Mod 2.3-4 CRCP 

8 

12/22/94 

Patrick Quach 

12/23/94 

12/27/94 

CP test cases 

9 

12/28/94 

Patrick Quach 

12/29/94 

12/29/94 

ASP test cases 

10 

1/11/95 

Patrick Quach 

1/12/95 

1/12/95 

CP test cases (related to 
SDCR #8) 

11 

2/7/95 

Patrick Quach, Debbie 
Taylor 

2/8/95 

2/8/95 

Subframe & Frame Drivers 

12 

2/8/95 

Patrick Quach 

2/9/95 

2/10/95 

Problem with subframe 
counter 

13 

2/11/95 

Debbie Taylor 

2/14/95 

2/14/95 

T est case drivers 

14 

2/15/95 

Patrick Quach 

2/16/95 

2/16/95 

Frame Test Cases 

15 

2/23/95 

Patrick Quach 

2/23/95 

2/24/95 

GP mathematica models 

16 

2/24/95 

Debbie Taylor 

2/24/95 

2/24/95 

GP structural test cases 

17 

2/24/95 

Debbie Taylor 

2/24/95 

2/24/95 

mathematica models 

18 

2/27/95 

Debbie Taylor 

2/27/95 

2/27/95 

Frame & Subframe 
command files 

19 

3/1/95 

Debbie Taylor 

3/1/95 

3/1/95 

oversight from SDCR #18 

20 

3/2/95 

Debbie Taylor 

3/2/95 

3/2/95 

everything from SDCR #18 
still not correct 

21 

3/3/95 

Patrick Quach 

3/6/95 

3/6/95 

Pluto GP structural test 
cases 

22 

3/7/95 

Debbie Taylor 

3/7/95 

3/7/95 

problem with driver for 
structural tests 

23 

3/10/95 

Debbie Taylor 

3/10/95 

3/10/95 

problem with mathematica 
structural test case model 
for TDLRSP 

24 

3/15/95 

Patrick Quach 

3/23/95 

3/23/95 

Requirements-based test 
cases for Spec Mod 2.3-7 
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Support Documentation Change Reports Assigned for Action 

Configuration Item: Software Verification Cases (test cases, models, drivers, etc.) 

SDCR# Date Assigned to: Date Received Date Comments 

Assigned (by Project Approved 

Leader (by SQA) 

25 3/15/95 Debbie Taylor 4/3/95 4/3/95 Mercury structural changes 

for Spec mod 2,3-7 

26 3/15/95 Patrick Quach 4/5/95 4/5/95 Pluto Structural changes for 

Spec Mod 2,3-7 

27 3/15/95 Debbie Taylor 3/16/95 3/16/95 Problems with Mercury 

structural test cases RECLP 

28 4/3/95 Patrick Quach 4/5/95 4/5/95 TDLRSP — model & all 

functional unit tests 

(TDLRSP, SP, Frame) 

29 4/3/95 Debbie Taylor 4/6/95 4/6/95 Mercury structural test cases 

for TDLRSP 

30 4/3/95 Patrick Quach 4/5/95 4/5/95 Pluto structural test cases 

for TDLRSP 

31 4/3/95 Patrick Quach 4/3/95 4/3/95 fix simulator support file 

32 4/7/95 Patrick Quach 4/7/95 4/7/95 remove debug statements 

from some Pluto link files 

33 4/7/95 Patrick Quach 4/7/95 4/7/95 

34 4/10/95 Debbie Taylor 4/10/95 4/10/95 wrong model used to 

generate Mercury structural 

test cases (see SDCR #25) 

35 4/10/95 Debbie Taylor 4/10/95 4/10/95 updated driver for trajectory 

testing 

36 4/10/95 Patrick Quach 4/10/95 4/10/95 Pluto structural test for ASP 

37 4/10/95 Patrick Quach 4/10/95 4/10/95 remove useless files 

38 4/14/95 Patrick Quach 4/14/95 4/14/95 renamed a trajectory run file 


to be Pluto specific (to be 
consistent with Mercury) 
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Support Documentation Change Reports Assigned for Action 


Configuration Item: GCS Specification 

Note: Version 2.2 of the GCS specification was the original version placed under configuration control. 
Changes 2.2-1 through 2.2-26 were made using a system of Formal Modifications prior to the 
project’s adoption of the Support Documentation Change Reporting system. Copies of Formal 
Mods 2.2-1 through 2.2-26 are shown in the Support Documentation Change Reports document; 
however, there was not log for those reports. 


SDCR # 

Date 

Assigned 

Assigned to: 

Date Received 
(by Project 
Leader 

Date 

Approved 
(by SQA) 

Comments 

2.2-27 

12/23/93 

Bernice Becher 

1/10/94 

1/13/94 

clarify Runge-Kutte method 

2.2-28 

1/19/94 

Bernice Becher 

1/26/94 

2/15/94 

clarify upper & lower limit 
exceeded requirements 

2.2-29 

2/15/94 

Bernice Becher 

3/15/94 

3/16/94 

lots of misc. changes 

2.3-1 

5/10/94 

Bernice Becher 

5/12/94 

5/13/94 

Misc. intro changes 

2.3-2 

5/13/94 

Bernice Becher 

5/19/94 

5/19/94 

Scheduling 

2.3-3 

5/25/94 

Bernice Becher 

6/8/94 

6/9/94 

Limit Checking 

2.3-4 

8/19/94 

Bernice Becher 

8/23/94 

8/24/94 

change to standard deviation 
formula & misc. 

2.3-5 

9/12/94 

Bernice Becher 

9/22/94 

9/23/94 

lots of misc. 

2.3-6 

1 1/22/94 

Bernice Becher 

12/21/94 

12/21/94 

change in preface + change 
CP for checksum 

2.3-7 

1/26/95 

Bernice Becher 

3/15/95 

3/15/95 

Pluto PR#27, ASP, GP 
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Appendix E: Problem Reports for the Pluto Implementation of the 
Guidance and Control Software Project 


This document was produced as part of Guidance and Control Software (GCS) Project conducted at 
NASA Langley Research Center. Although some of the requirements for the Guidance and Control 
Software application were derived from the NASA Viking Mission to Mars, this document does not 
contain data from an actual NASA mission. 
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GCS Problem Report 


2. Planet: 
PLUTO 


3. Discovery Date: 
Oct 15, 1993 


age 1 of 


4. Initiator & Role: 

Inspectors / Angcllnttn and Bechcr 


5. Activity at Discovery: 


* Activity 

Development Phases I DR I CR I RC | RS 1 TOR 1 TCR | TCC 1 TCE 1 R O 
Design 

code 

Unit Testing 

Functional ^ . 

Structural < 

Subframe Testing 

Frame Testing ^ 

Top-Level Simulator ^ 

Integration Testing 


6. Description of Problem: 

The Teamwork balance operation indicates the existence of errors in the Pluto design. In accordance with the Software Design 
Standards, the Pluto design is to be modified such that the Teamwork balance operation indicates an absence of errors. The 
Teamwork balance report is attached. 


7. Artifact Identification: 

X Design Description 

Source Code 

Executable Object Code 


Support Documentation 

Other 


Configuration Item: 

Pluto Design Description 


8. Test Case Identification: 


9. History Log: 

Date To 1 Date From [ Person 


A RioiC’nrVcr 


Comments 





2. Initiator Signature & D4fe / 1 3. SOA^Sienature & Dat 6 ) 

Original Signed by faec. ■ ft /o Original Signed by 7 

Rob Angellatta George Finelli 

* Activity: DR - Design Review; CR - Code Review; RC - Reading Code; RS - Reading Specification; TRR 


i mi 


- Test Readiness 
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Problem Report Continuation 


a. Report #: Pluto PR #1. 


page 2 of 18 



b. Notes/Explanation (Please reference appropriate section number): 

DTD checking 

Copyright 19*6. 19*7. 19**. 19*9, 1990, 1991. 1992. 

Cadre Technologic* Inc. 

All right* reserved. 

Dite: Wed 20 Oct 1993 Time: 11:36:16 

Version: Teamwork 4.1 

DFD checking option*: 

outpul : /Cidre/f e p o ru/|cs.plu to.,d f d .con lex I .1 010. 113 5 * 

conflg : /cadre/tsa/eonflg_flle 

model : O C S . p I u t o . I 1 _ 0 

object : Context-Diagram 

type of check: DFD Syntax and Balancing of Child Proceiin and CSpec 

extent : Sub-tree 

dde expansion: Unlimited 

report *ty!e : Verbose 

unmatched Report Unmatched - C-Spec Flows 

DFD: Context-Dlagram:l2 ’ O C S ’ 

Flows: 

1 The data flow ' I N I T U L I 7 A T I O N . D A T A ' has an Invalid definition. 

Syntax error on fine 3 reading *4*: • 

4 A. ACCELERATION 

2 The data flow ’PACKET’ has an Invalid definition. 

A comment Is not terminated on line 5 reading *•*: 

DATA TYPE: a r r a y ( I . . 2 5 6 ) of I n t e g e r • 2 : 

No CSpec balancing errors on this diagram. 

No DFD/P-Spec balancing errors on this diagram. 

No store-to-flow constituent errors on this diagram. 

No syntax errors on this diagram. 

DFD: 0:17 'INIT.R UN.OCS 1 

Flows: 

3 The control flow 'INIT.DONE' has an Invalid definition. 

Syntax error on line t reading * : ' : 

•INIT.DONE - ; 

4 The control flow 'RUN.DONE' has an Invalid definition. 

A comment Is not terminated on line 6 reading ' * ' : 

DATA TYPE: logical - !: 

5 The data flow 'FRA ME. COUNTER* has an Invalid definition, 

A comment Is not terminated on line 6 reading ’•*: 

DATA TYPE: lnteger - 4: 

No C-Spec balancing errors on this diagram. 

No DFD/P-Spec balancing error* on this diagram. 

No store*to-flow constituent errors on this diagram. 

No tyntax errors on this diagram. 


PAT: 0 *1:13 '1N1T.RUN.OCS PAT* 

Input Events: 

Column 2. DDE ’INIT.DONE * has a 
Syntax error on line I reading ' • ' • 
•INIT.DONE*; 


or In Its definition 


Column 3, DDE *RUN_DONE' has a syntax error In Its definition 
A comment Is not terminated on line 6 reading *•*: 

DATA TYPE: logical - !: 


P-Spec: i;9 'INIT.OCS' 

No syntax errors In the I/O list. 
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Problem Report Continuation 

page JL of 

Report #: Pluto PR #JL0 — “ 

Notes/Explanation (Please reference appropriate section number): ~ “ 

DFD: 2 ; 5 I 'RUN.OCS' 

Bubble*: 

D... Comp" !> " 0 ' m,,Ch "" ChM< ' DrD '*BC..P. A.I.I Engine 

r. .....V, ifSVoV,?'"'-''. Ch " d DrD ,TOSf - T -'‘ «>•-- s«". 

1 r,..,.".: b I b D e .,v E ', T p s . p „'a d ::5 B cV»p,v. c , b .. ,be ch,,d DFD " ,,e 

1 D... E.V.Vd'.nV c"*V.«V,V n °' m,,Ch ,h ' Ch " d DPD ’ARSP-Altlmete/ Rtdar 

2 E x p ■ n d B ■'n'd* 'c o m p ^ /j/V' , d ° * n °' ,h * ' " " d 0 F D ' A S P . A c e e . e r o m e , e , D... 


Bubble 4 ‘CP* d 


rroc.,„, niia B,p,.r: n n ;t,":;!:,:f t ch,,d DrD 

. B .“ b . b D e .. 6 . ch,,d dfd ,,,,e se „,„ r 

Da,. E ®p U „ 7 d '°c P 0 m d 01 m * ,Ch ’OP-Ouldance Pro** 

C o n I ro f L^iV V m c ( m^I n | • / ° f " n0 ' ' Ch " d DrD ' * p - C L P - R o I. Engine 

L. n d 1 „^R^v^%; T „^^ Rs p:;// D v,;v,p n, .v^ h o m , P ^^. ch,ld dfd ,n " »•«- 

P-Spec 'l.lf tilm, but bubble II Is missing. 

Flows: 

ACCEL.OS.IN' Is not • conslliuenl of store 'GUIDANCE .STATE'. 

A C C E L _ 0 S . O U T ' Is not i constituent of store ' O U I D A N C E _ S T A T E • 

'ACCEL.RP.IN' Is not i constituent of store 'R UN .P A R A H E TER S' , 

' A C C E L . S O _ I N ' Is not > constituent of store ' S E N S O R . O U T P U T • . 

'ACCEL.SO.OUT' 1s not > constituent of store ’SENSOR.OUTPUT'. 

' A P. _ C M D ' has an Invalid definition. 

A comment Is not terminated on line 3 readln) •••; 

DATA TYPE: a r r a y ( I . . } ) of I n t e g e r * 2 : 

'A F._ STATUS' bas an Invalid definition. 

A comment Is not terminated on tine 3 reading • • ■ • 

DATA TYPE: Logical*!: 

'AE.SWITCII' has an Invalid definition. 

A comment Is not terminated on line 7 reading • • • • 

DATATYPE: Logical*!: 

'AE.TEMP' has an Invalid definition. 

A comment Is not terminated on line 6 reading •*•• 

DATA TYPE: Logical*!; 

•ALPHA. MATRIX' has an Invalid definition. 

A comment Is not terminated on line 3 reading 
DATA TYPE: a r r a y ( I . . 3 , | . . j ) „f r e a • It ; 

■ALT.RAD.OS.IN' Is not , constituent of store 1 0 U I D A N C E . S T A T E ' . 
'ALT.RAO.US.OUT' Is nol a constituent of store 'OUIDANCE.STATE'. 

'ALT. RAD. RP. IN' Is not a constituent of store 'RUN. PARA METERS'. 

' A L T - » * D - S O . 1 N ' 1s not a constltuen t of store 'SENSOR.OUTPUT' 
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Problem Report Continuation 


a. Report #: 

Pluto PR #1.0 


b. Notes/Explanation (Please reference appropriate section number): 


3 3 

'ALT^R AD.SO.OUT' Is not a constituent of store * S 

ENSOR. OUTPUT*. 

3 4 

'AR.ALTITUDE' ha* an Invalid definition, 

A comment It not terminated on line 5 reading 
DATA TYPE: array(0..4> of Real**; 


3 5 

'AR.COUNTER' has an Invalid definition. 

A comment Is not terminated on line 6 reading ' * ' : 
DATA TYPE: Integer*!: 

t 

36 

' A R _ F R E QUENCV till an Invalid definition. 

A comment la not terminated on line 5 reading ' • • 
DATA TYPE: Real**: 


3 7 

•AR. STATUS' It a a an Invalid definition. 

A comment la not terminated on line 5 reading 
DATA TYPE: » r r i y f 0 . . 4 ) of Logical’!: 


3 8 

•ATMOSPIIEREIC.TEMP' la undefined. 


3 9 

'ATMOSPIIERIC.TEMP' has an Invalid definition. 

A comment 1* not terminated on line 5 reading * * ‘ ; 
DATA TYPE: Real**: 


4 0 

'AX.ENO.OS.fN' la not a constituent of atore 'GUI 

D ANCE.ST ATE*. 

4 1 

'AX.ENO.OS.OIIT' la not a conatltuent of atore 'OUIDANCE.STATE'. 

4 2 

'AX.ENO.RP.IN* Is not a constituent of store ’RUN 

.PARAMETERS’. 

4 3 

'AX.ENO.SO.IN' Is not a constituent of store ’SEN 

SOR .OUTPUT*. 

4 4 

'A.ACCELER ATION' has an Invalid definition. 

A comment Is not terminated on line 5 reading **': 
DATA TYPE: array(l..3,0..4) of teilM; 


4 5 

' A . B 1 A S ' has an Invalid definition. 

A comment Is not terminated on line 6 reading 
DATA TYPE: a rr a y ( 1 . . 3 ) of re a 1 * R ; 


4 6 

1 A . O A 1 N . 0 1 has an Invalid definition. 

A comment Is not terminated on line 5 reading * * * ; 
DATA TYPE: »rray( 1 .. J) of Reil’R; 


4 7 

' A.SCALE' has an Invalid definition. 

A comment Is not terminated on line 6 reading 
DATA TYPE: Integer-4; 


4 8 

'A.STATUS' has an Invalid definition. 

A comment Is not terminated on line <5 reading 
DATA TYPE: array(l..3.0..3) of Logical*!* 


4 9 

'C II OTE.RE LEASE' Is not a constituent of store 'OUIDANCB.STATB'. 

5 0 

*CHUTE. RELEASED' has an Invalid definition. 

A comment Is not terminated on line 6 reading *•*: 
DATA TYPE: Logical*!; 


5 1 

'CIIUTE.REL_OS„IN' Is not a constituent of store * 

GUIDANCE. STATE'. 

5 2 

'CHUTE.REL.OS.OUT' Is not a constituent of store 

•OUIDANCE.STATE*. 

5 3 

'CL' has an Invalid definition. 

A comment Is not terminated on line 6 reading *•': 
DATA TYPE: Integer*!; 
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5 4 

' c 

L ' o u i 

1 o f 

child 

DFD 

2 

.4 la u n m a t c 

h e d . 





5 5 

* c 

L * o u i 

1 o f 

child 

DFD 

2 

.7 la u n m a t c 

h c d . 





5 6 

• c 

0 M M _ 

OS. 

1 N * 

1 a 

n o t 

a 

tomllluenl 

of a t o r e 

'OUID 

A 

N 

CF, .STATE*. 

5 7 

• c 

O M M . 

OS. 

OUT 

• 

la no 

t 

a conatltuen 

t of a t o r 

c 'QUID 

A 

NCE.STATE 

5 8 

• c 

O M M _ 

R P _ 

I N * 

1 a 

n o t 

a 

constituent 

of a t o r e 

'RUN. 

P 

A 

RA METERS' 

5 9 

• c 

O M M _ 

SO. 

1 N * 

1 a 

n o t 

a 

conatltuent 

of a t o r e 

'SENS 

O 

R 

.OUTPUT*. 

6 0 

' c 

O M M _ 

S Y N C _ P 

A 

T T E R 

N ' 

haa an Inva 

lid d e f 1 n 

! t 1 o n . 





A 

comm 

c n 1 

1 a n 

0 l 

t e r m 1 

n i led on tin 

e 5 r e a d 1 

n g ' * ' : 





DATA TYPE: I n 1 e g e r * 2 : 

61 ’CONTOUR .ALTITUDE' h a a an Invalid definition. 

A comment Is not terminated on line 5 reading 

DATA TYPE: ■ r r i y ( 1 . . I 0 0 ) of Real**; 

62 'CONTOUR. CROSSED* haa an Invalid definition. 

A comment la not terminated on tine 6 reading *•': 
DATA TYPE: logical* 1 : 

63 'CONTOUR. VELOCITY* ha* an Invalid definition. 

A comment la not terminated on line 5 reading 

DATA TYPE: • r r ■ y ( I . . I 0 0 ) of Real**: 

'C.STATUS* has an Invalid definition. 

A comment la not terminated on line 7 reading *•*: 

DATA TYPE: Logical*!: 

65 'DELTA. T ' haa an Invalid definition. 

A comment la not terminated on line 5 reading **': 

DATA TYPE: Real**: 

66 'DELTA.T* out of child DFD 2.* la unmatched. 

67 'DROP. II EIGHT' has an Invalid definition. 

A comment la not terminated on line 6 reading **’: 

DATA TYPE: Real**: 

68 'DROP. SPEED' haa an Invalid definition. 

A comment I* not terminated on line 6 reading ***: 

DATA TYPE: Real**: 

69 'ENOINES.OFF* la undefined. 

70 'ENGINES. ON. ALTITUDE* haa an Invalid definition. 

A comment Is not terminated on line 6 reading ***: 

DATA TYPE: Real**: 

71 'FR A ME. BEAM .UNLOCKED* has an Invalid definition. 

A comment la not terminated on line 7 reading '**: 

DATA TYPE: array(l..4) of lnteger*4; 

72 'FRAME. COUNTER' out of child DFD 2.2 Is unmatched. 

73 'FRAME. ENGINES. IGNITED' haa an Invalid definition. 

A comment la not terminated on line 7 reading * • ' ; 

DATA TYPE: lnteger‘4; 

' F U L L _ U P _ T I M E ' haa an Invalid 
A comment la not terminated on 

DATA TYPE: Reil'l; 


4 


definition, 
line <5 reading * 




Problem Report Continuation 


page 6 of 18 


a. Report #: Pluto PR #1.0 


b. Notcs/Explanation (Please reference appropriate section number): 


7 5 

’OA' has an Invalid definition. 

A comment Is not terminated on line 5 reading # 
DATA TYPE: Real**: 

* ' : 


7 0 

'OAX* has an Invalid definition. 

A comment Is not terminated on line 5 reading ' 
DATA TYPE: Real**; 

• ' : 


7 7 

' 0 P Y * has an Invalid definition. 

A comment Is not terminated on Itne 3 reading * 
DATA TYPE: Real**: 

• 1 : 


7 8 

'OPI' has an Invalid definition. 

A comment Is not terminated on line 5 reading * 
DATA TYPE: Real**: 

• ' : 


7 9 

'OP2' has an Invalid definition. 

A comment Is not terminated on line 5 reading ' 
DATA TYPE: Real**; 

• ' : 


8 0 

'OP. ALTITUDE' has an Invalid definition. 

A comment Is not terminated on line 3 reading ’ 
DATA TYPE: a r r a y ( 0 . . 4 ) of Real**: 



8 1 

'OP.ATTITUDB' has an Invalid definition. 

A comment Is not terminated on line 3 reading 
DATA TYPE: a r r a y ( 1 . . 3 . 1 . J . 0 , . < ) Real**: 

• 


8 2 

'OP.ATTITUDE' out of child DFD 2.1 Is unmatch 

e d . 


8 3 

'OP.PIIASE' has an Invalid definition. 

A comment Is not terminated on line 6 reading 
DATA TYPE: 1 n t e g e r • 4 ; 



8 4 

'OP.ROTATION' has an Invalid definition. 

A comment Is not terminated on line 6 reading 
DATA TYPE: ■ r r a y ( 1 . . 3 , 1 . . 3 ) Real**: 

• • : 


8 5 

'OP.VELOCITY' has an Invalid definition. 

A comment Is not terminated on line 6 reading 
DATA TYPE: a r r a y ( 1 . . 3 , 0 . . 4 ) of Real**: 

• 


8 6 

'OQ' has an Invalid definition. 

A comment Is not terminated on line 3 reading 
DATA TYPE: a r r a y ( 1 . . 2 ) of Real**; 

• • : 


8 7 

'OR' has an Invalid definition. 

A comment Is not terminated on line 3 reading 
DATA TYPE: arriyfl.J) of Real**: 

. . . . 


8 8 

•GRAVITY' has an Invalid definition. 

A comment Is not terminated on line 5 reading 
DATA TYPE: Real**: 

.... 


8 9 

'OUIDE.OS.IN' Is not a constituent of store *0 

U 1 D 

ANCE .STATE*. 

9 0 

'OUIDE.OS.OUT' Is not a constituent of store 

OUIDANCE.STATE 

9 1 

'OUIDE.RP.IN' Is not a constituent of store ‘R 

UN. 

PARAMETERS' 

9 2 

'CUIDE.SO .IN' Is not a constituent of store 'SENSOR.OUTPUT*. 

9 3 

' 0 V * has an Invalid definition, 

A comment Is not terminated on line 3 reading 
DATA TYPE: array(l..2) of Real**: 

* * • . 
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4 

5 

e 

7 

8 
> 9 

0 0 
0 1 
I 0 2 
I 0 3 

. 0 4 

1 0 5 

1 0 6 

1 0 7 

1 0 8 

1 0 9 

1 1 0 

111 
' 2 
, .13 


'O VE' ha* an I n v i I I d definition. 

A comment I* not lermlnited on line 5 rcidlnf ' * ' : 

DATA TYPE: Itll'l: 

' O V E I ' hi* in Invltld definition. 

A comment I t not lermlnited on line 5 r e • d I n g 

DATA TYPE: irri r ( I . .1 I of Beil**: 

'GW* hi* in Invltld definition. 

A comment ll not termlnlted on line 3 reading ’ * ’ : 

DATA TYPE: i r r i y < I . . 2 > of Reil**: 


• O W | * hit in Invltld definition. 

A comment I* not lermlnited on line 3 reading ' * 

DATA TYPE: a r r • y ( I . . 2 ) of R e • I • * : 

'OYRO.OS.IN' I* not • constituent of itore •GUIDANCE. STATE . 

'OYRO.GS.OUT* I* not • conitltuent of store 'GUIDANCE .STATE . 
•GYRO. RP. IN' I* not i constituent of store 'RUN. PARA METERS'. 

•GYRO. SO. IN' Is not ■ constituent of store 'SENSOR. OUTPUT . 

•OYRO.SO.OUT* Is not 1 constituent of store 'SENSOR.OUTPUT . 

• O I ' hi* in Invilld definition. 

A comment I* not terminated on line 5 reading ' * * • 

DATA TYPE: Real 4 *: 


• O ! ' ha* an Invalid definition. 

A comment l« not terminated on line 5 reading * * 
DATA TYPE: Real**: 


' O J ' hat an Invalid definition. 

A comment Is not lermlnited on line 5 reidlnt '•': 
DATA TYPE: Reil’l: 


*04* ha* an Invalid definition. 

A comment Is not lermlnited on line 3 reidlnt '•': 

DATA TYPE: R e i I * * : 

'G.OAIN.O* hit in Invilld definition. 

A comment Is not termlnlted on line 6 reidlnt '•': 

DATA TYPE: • r r I y ( I . . 3 ) of Reil**: 

'G.OFFSET' his in Invilld definition. 

A comment Is not termlnlted on line « reidlnj '*': 

DATA TYPE: • r r ly ( I . . J ) of Reil**: 


'G.ROTATION' hi* in Invilld definition. 

A comment Is not termlnlted on line 3 reidlnt 
DATA TYPE: arrly(t..3.0..4) of Reel**: 


'G.STATUS* his in Invilld definition. 

A comment Is not termlnlted on line 5 reidlnt 
DATA TYPE: LotlcilM: 


'INIT.GS.OUT' Is not 
•INIT.RP.OUT' Is not 


I constituent of store 'OUIDANCE.STATE'. 
i constituent of store 'RUN.PARAMETF. RS 


■ INTERNAL.CMD' his in Invilld definition. 

A comment Is not termlnlted on line 6 reidlnt '*': 
DATA TYPE: i r r i y ( I . . 3 I of Reil'l: 


' K _ A L T ' his in Invilld definition. 

A comment Is not lermlnited on lEofr 6 f * 1 d 1 " » '•': 


1 1 4 
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DATA TYPE: irr«y(0..4) of lnlt|tiM : 

118 'K. MATRIX 1 hat in Invalid definition. 

A comment la not terminated on line 6 reading 
DATA TYPE: a r r a y ( I . . J . | , . j . o . . 4 ) lnteter‘4; 

116 ’MAX. NORMAL. VELOCITY' hat an Invalid deflnltlo 

A comment la not terminated on line 6 reading •••■ 
DATA TYPE: l t ■ I * R ; 

117 'MAX. NORMAL. VELOCITY 1 out of child DFD 7.1 I. 

118 "Ml- bat an Invalid definition. 

A comment la not terminated on line 7 reading • • • • 
DATA TYPE:lnterger*2; 

119 'Ml' bat an Invalid definition. 

A comment It not terminated on line 7 reading • • • • 
DATA TYfE: Integer-!; 

120 -M3' hat an Invalid definition. 

A comment It not terminated on line 7 reading 
DATA TYPE: Integer-!: 

121 • M 4 • hat an Invalid definition. 

A comment It not terminated on line 7 reading 
DATA TYPE: Integer*!; 

22 -OMEOA- hat an Invalid definition. 

A comment It not terminated on line 5 reading 
DATA TYPE: r e a I • It : 

23 -PE.INTEOR AL" hat an Invalid definition. 

A comment It not terminated on line 3 reading •••• 
DATA TYPE: rt t I* b ; 

24 -PE. MAX- hat an Invalid definition. 

A comment It not terminated on line 5 reading 
DATA TYPE: array(l..2) of real**; 

25 "PE. MIN" hat an Invalid definition. 

A comment It not terminated on line 3 reading 
DATA TYPE: array(l..2) of real**: 

26 -PI - hat an Invalid definition. 

A comment It not terminated on line 3 reading • • • • 
DATA TYPE: real**; 

27 -PJ- hat an Invalid definition. 

A comment It not terminated on line 5 reading '••• 
DATA TYPE: i e • I * I ; 

28 -P3- hat an Invalid definition. 

A comment It not terminated on line 5 reading •••; 
DATA TYPE: r e a I * a ; 

29 • P 4 * hat an Invalid definition. 

A comment It not terminated on line 5 reading • • • • 
data TYPE: real-1; 


unmatched 


-RE.CMD- hat an Invalid definition. 

A comment It not terminated on line « reading 
DATA TYPE: Inltgti-i; 

-RE.STATUS- hat an Invalid definition. 

A comment It not term! nated on line 3 reading 
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1 3 2 

1 3 3 
1 3 4 
1 3 6 
1 3 6 
1 3 7 
1 3 8 

1 3 9 

1 4 0 

' 4 1 

1 4 2 

1 4 3 

1 4 4 

1 4 5 
1 4 6 

1 4 7 
1 4 8 
1 4 9 
1 5 0 
1 5 1 
1 5 2 
5 3 


DATA TYPE: logical*! ; 

•RE.SWITCII' kn an Invalid definition. 

A comment la not tetmlnated on line 6 reading 
DATA TYPE: logical' I : 

'ROL.ENO.OS.IN' la not a conatltuen! of atore 'GUIDANCE .STATE'. 

'ROL.ENO.OS.OUT' la not a conatltnent of atore 'OUlDANCE.STATBj. 

'ROI._ENO_RP.IN' la not a conatltuenl of atote 'RIIN.PARAMETERS'. 

■ROI. _ENO.SO.IN' la not a conatltuenl of atore 'SENSOR .OUTPUT'. 

■TDLRSP.SWITCII' la undefined. 

•TDLR.ANOLES' baa an Invalid definition. 

A comment la not terminated on line 6 reading ' • ' : 

DATA TYPE: a r r a y ( I . . J ) of real**: 

■TDLR.CIAIN' hit an Invalid definition. 

A comment la not terminated on line 5 reading 

DATA TYPE: real**: 

' T D l. R _ L O C K _ T I M E ' baa an Invalid definition. 

A comment la nol terminated on line 5 reading 

DATA TYPE: real**: 

•TDLR. OFFSET' haa an Invalid definition. 

A comment la not terminated on line 5 reading '•': 

DATA TYPE: real**: 

'TDLR.STATE' haa an Invalid definition. 

A comment la not terminated on line 6 reading ’*': 

DATA TYPE: anayl I ..<) logical*!: 

'TDLR. STATUS' haa an Invalid definition. 

A comment la nol terminated on line 5 reading '*': 

DATA TYPE: a r r a y ( I . . 4 ) of logical*!; 

'TDLR.VELOCITY' haa an Invalid definition. 

A comment la nol terminated on line 6 reading '•': 

DATA TYPE: array(1..3.0..4) of real**: 

'TDSP.SWITCII' la undefined. 

■TDS.STATUS' baa an Invalid definition. 

A comment la nol terminated on line 5 reading '•': 

DATA TYPE: logical*!: 

•TD.OS.IN' la nol a conatltuenl of atore 'OUIDANCE.STATB'. 
'TD.OS.OUT' la nol a conatltuenl of atore 'OUIDANCE.STATE'. 

'TD.lND.RAD.OS.lv la not a conatltuenl of atore 'OUIDANCE.STATE'. 

'TD_l.ND_RAD_OS.OUT' la not a conatltuenl of atore 'OUIDANCE.STATE' 
■TD.LND_RAD_RP.IN' la not a conatltuenl of atore 'RUN.PARA METERS'. 

•TD.LND_RAD_SO.IN' la not a conatltuenl of atore 'SENSOR.OUTPUT'. 

'TD_LND_RAD.SO.OUT' la not a conatltuenl of atore 'SENSOR.OUTPUT'. 
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154 'TD.SENSED' hit in Invalid definition. 

A comment I* not terminated on line 6 reading ' * * : 

DATA TYPE: logical*!: 

15 5 ’TD.SO.OUT' I 8 not a constituent of store ' S E N S O R . O UTP UT'. 

150 'TEMP.OS.IN' Is not • constituent of store 'OUIDANCE.STATE'. 

157 'TEMP.OS.OUT' Is not a constituent of store 'OUIDANCE.STATE' 

150 'TEMP.RP.IN 1 ts not a constituent of store 'RUN.PARA METERS'. 

159 'TEMP.SO.OUT' Is not a constituent of store 'SENSOR.OUTPUT'. 

100 'TE.DROP' has an Invalid definition. 

A comment Is not terminated on line 7 reading ’*': 

DATA TYPE: real**: 

101 ' TE . I N I T’ has an Invalid definition. 

A comment Is not terminated on line 6 reading * * * : 

DATA TYPE: r e • I * * : 

162 'TE.INTP. OR A L ' has an Invalid definition. 

A comment Is not terminated on line 5 reading * * ' : 

DATA TYPE: real**; 

183 'TE .INTEOR AL' out of child DTD 2.7 Is unmatched. 

164 ' T E _ L I M I T * has an Invalid definition. 

A comment Is not terminated on line 5 reading *•': 

DATA TYPE: real**: 

105 ' T E . M A X ' has an Invalid definition. 

A comment Is not terminated on line 5 reading ' * * : 

DATA TYPE: a r r a y ( I . . 2 ) of real**: 

100 'TEAMIN' has an Invalid definition. 

A comment Is not terminated on line 5 reading * * * : 

DATA TYPE: • r r a y ( I . . 2 ) of real**: 

107 'THETA' hat an Invalid definition. 

A comment Is not terminated on line 5 reading ' * ' : 

DATA TYPE: real**: 

108 ' T II E T A I ' has an Invalid definition. 

A comment Is not terminated on line 5 reading 

DATA TYPE: real**: 

109 1 T II E T A 2 ' has an invalid definition. 

A comment Is not terminated on line 5 reading '*’: 

DATA TYPE: real**: 

170 'TS.STATUS' has an invalid definition. 

A comment Is not terminated on line 7 reading ' * * : 

DATA TYPE: irriy ( I . . 2 ) of logical*!: 

171 ' T I ' has an Invalid definition. 

A comment Is not terminated on line 7 reading ***: 

DATA TYPE: real**: 

172 * T 2 ' has an Invalid definition. 

A comment Is not terminated on line 7 reading *•': 

DATA TYPE: real**; 


' T 3 ' has an Invalid definition. 

A comment Is not terminated on line 7 reading '*': 
DATA TYPE: real**: 
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1 7 4 


1 7 5 


1 7 6 


1 7 7 


1 7 8 


1 7 0 


1 8 0 


• T 4 * ha* an Invalid definition. 

A comment I* not terminated on line 7 reading ***: 

DATA TYPE: real**; 

'VElOCITY.ERROr ha* an Invalid definition. 

A comment I* not terminated on line 7 reading * * * : 

DATA TYPE: real's : 

I 

•YEJNTEORAL' hi* an Invalid definition. 

A comment 1* not terminated on line 5 reading *•*: 

DATA TYPE: r e a I • * : 

' Y E . M A X ' ha* an Invalid definition. 

A comment I* not terminated on line 5 reading **’: 

DATA TYPE: a r r a y ( I . . 2 ) of real**: 

' Y E . M I N ' ha* an Invalid definition. 

A comment I* not terminated on line 5 reading ' • * : 

DATA TYPE: a r r a y ( I . . 2 ) of real's* 

The control flow 1 S U fl F R AME.COUNTER' ha* an Invalid definition. 

A comment I* not terminated on line 5 reading 

DATA TYPE: lnteger'2: * 

The control flow 'SUBER AME.COUNTER' la defined In the Data Dictionary a* a 
data flow. 

Store*: 


3 1 

T h e 

s I 

ore 

• 0 U 1 D A N C 

E . S T A T E ‘ 

Is defined In the Data Dictionary a* a flow. 

d 2 

The 

* 1 

lore 

* O U 1 D A N C 

E.STATE' 

I* undefined. 

1 8 3 

The 

« i 

lore 

'RUN.PAR 

AMETERS 1 

1* defined In the Data Dictionary at a flow 

1 8 4 

The 

S 1 

lore 

'RUN.PAR 

A M E T E R S ' 

Is undefined. 

1 8 5 

The 

9 

lore 

•SENSOR. 

OUTPUT* 1 

1* defined In the Data Dictionary a* a flow. 

1 8 6 

T h e 

« 

tore 

'SENSOR. 

OUTPUT* 1 

Is undefined. 


No C-Spec balancing error* on thl* diagram. 

No ayntax errors on thl* diagram. 

PAT: 2 - s I ; I 3 ‘PAT • CONTROL ORDER OF EXECUTION OF MODULES IN RUN.OCS' 

Input Event*: 


1 8 7 

Column 

1 , 

’ F ' 1* not a constituent 

0 f 

1 8 8 

Column 

1 . 

DDE * F * 1* not a dlicre 

t e e 

1 8 9 

Column 

1 . 

DDE MTII.FR AME.2' Is 

n o t 

1 9 0 

Column 

2 . 

* F ' li not a constituent 

o f 

1 9 1 

Column 

2 . 

DDE * F ' li not a dlscre 

1 e e 

1 9 2 

Column 

2 . 

DDE 'ITII.FR AME.J' I* 

n o t 

1 9 3 

Column 

3 . 

DDE 1 R E N D E Z V 0 U S _ C N T L ’ 

1 9 4 

Column 

4 . 

' F ' Is not • constituent 

1 o f 

1 5 

Column 

4 . 

DDE ' E N D _ 0 C S ‘ Is nol 

a d 1 

1 9 0 

Column 

4 , 

DDE ' F 1 Is nol i dlscte 

t e e 
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. . Wotes/Explanation (Please reference appropriate section number): 
2 1 5 
2 1 6 


2 1 7 


Bubble 2 *TDSP*Touch Down Senior Processing* does not much the child P - 
Spec title *TD5P-Touch Down Sensor Proce**ln|(P-SPEC 2.1.6)*. 


Bubble 3 'TDSP-Touch Down Compress Dali Plows' doe* not milch the child P - 
Spec title ‘TDSP-Touch Down Sensor Processing Compress Dili Plows’. 

Flows: 

The data flow 'TD.COUNTER' has an Invalid definition. 




A comment Is 

not terminated on line 3 

reading 






DATA TYPE: 1 

n t e g e r * 2 : 




t 


N o 

C-Spec balanc 

1 n | errors on this diagra 

m . 





N o 

DFD/P-Spec b 

■lancing errors on this d! 

1 a g r a m . 





N o 

store-to-flow 

constituent errors on thl 

s diagra 

m . 




N o 

syntax errors 

on this diagram. 





p . 

Spec 

t 2.10.1*7 * T 

DSP • Touch Down Sensor 

Process 

1 n g 

Expand Dal 

a Flow* 


N o 

syntax errors 

In the I/O 11 x t . 





p 

Spec 

: 2.10.2:12 

TDSP Touch Down Senso 

r P rot M 

s 1 n 

g ( P - S P E C 2 

.1.6)* 


N o 

syntax errors 

In the I/O list. 






P-Spec: 2.10.3:5 'TDSP - Touch Down Sensor Processing Compress Data Plows* 

No syntax errors In the I/O list. 


• T S P 


Temperature Sensor Processing Data Expand and Compress* 


2 1 8 


D P D : 2.11:2 

Bubbles: 

Bubble 2 ' T S P • T e m p e r i hi r e Sensor Processing' does not match the child P-Spec 

title ‘TSP-Temperature Senior Processlng(P-Spec2.l.5)*. 


Flows: 

'TS.STATUS' Into bubble 2 Is unmatched. 

The data flow ' S S . T E M P ' has an Invalid definition. 

A comment Is not terminated on line 5 reading 
DATA TYPE:lnteger*2: 

The data flow * T II E R MO.TEMP' has an Invalid definition. 
A comment Is not terminated on line 3 reading *•': 

DATA TYPE: Integer* 2: 



N o 

C 

-Spec 

balancing 

error* 

o n 

this 

d 1 a 

gram. 





N o 

s 

t o r e - t 

o - f 1 o w con 

s t 1 t u e n 

t e r 

r o r s 

o n 

this d 1 

a 

gram. 



N o 

s 

y n t a x 

errors on 

this d 1 

a g r a 

m . 






P - S 

pec 


2.11. 

i : i * t s p ■ 

T e m p e 

r i tu 

r e S 

e n s 

or P r o c 

e 

9 s 1 n g 

Data Expand' 


N o 

9 

y n t a x 

errors In 

ihe I/O 

1 1 s 

t . 






P - S 

pec 


2.11. 

2:10 * T S p 

Temp 

e r a t 
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P*Spcc: 2.11.3:1 *TSP Temperature Sensor Processing Data Compress* 

No syntax errors In ihe I/O list. 


9 

2 2 0 
2 2 1 


P-Spec: 2.13:2 'STORE 

No syntax errors In 


RAW SENSOR 
Ihe I/O list. 


DATA' 


P-Spec: 2.1 4 ; 2 '1N1T RUN FARM STORE* 

No syntax errors In the I/O list. 

P-Spec: 2.15:2 ’ 1 N 1 T OUIDANCE STATE STORE’ 

No syntax errors In the I/O list. 

P-Spec: 2.16:3 ’SEND CHUTE RELEASE COMMAND* 

1/0 E n t r I e i : 

222 'CIIUTE.REIEASE' Is an Input control flow. 
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a. Report # Pluto PR #1. 


b. Notes/Explanation (Please reference appropriate section number): 

P-Spec: :.l7i3 'SEND ENOINF. DATA' 

No syntax error* In the I/O list. 

P * S p e c : 1 . t * { * ‘COPY CONTROL DATA* 

I/O R n l r I ei : 

223 'INIT.RND.OCS' Is an Input control flow. 

224 •INIT.RRHDEZVOUS.CNU' Is in Input control flow. 

225 'IN1T.SUBFR AME.COUNTER' Is an Input control flow. 1 

228 'RENDEZVOUS .CNTL' Is in Input control flow. 

DFD: 2 . 2 ; 5 'ARSE Altimeter Radar Data Expand and Compress' 

Bubbles: 

227 Bubble 2 'ARSP-Altlmeter Radar Sensor Processing* doei not match the child 

P-Spec title 'ARSP-Altlmeter Radar Sensor Processlng(P-Spec 2. 1.2)'. 

Flows: 


2 2 8 

'FRAME. 

COUNTER' 

2 2 9 

'FRAME. 

COUNTER' 

2 3 0 

•K. ALT' 

Into child 

2 3 1 

'K. ALT' 

out of bub 


No C-Spec balancing errors on this d 1 t | t i m . 

No DDE errors on this diagram. 

No store-to-flow constituent errors on this diagram. 

No syntax errors on this diagram. 

P-Spec: 2.2. I : 3 'ARSE Altimeter Radar F. xpand Data Flows* 

No syntax errors In the I/O list. 

P-Spec: 2.2.2;22 'ARSE Altimeter Radar Sensor Processlng(P-Spec 2.1.2)* 

No syntax errors In the I/O list. 

P-Spec: 2. 2. 3:3 'ARSE Altimeter Radar Compress Data Flows* 

No syntax errors In the I/O list. 

DFD: 2.3:5 ‘ASP Accelerometer Data Expand and Compress' 

Bubbles: 

Bubble 2 'ASP-Accelerometer Sensor Processing* does not match the child P 
Spec title ’ASP-Accelerometer Sensor Processlng(P-Spec 2.1.1)*. 

Flows: 

* A _ ACCCELE RATION* Into child P-Spec 2.3.2 Is unmatched. 

'A. ACCELERATION' Into bubble 2 Is unmatched. 

The data flow 'A.COUHTER' has an Invalid definition. 

A comment is not terminated on line 6 reading ' • * : 

DATA TYPE: a r r a y ( I . . 3 ) of I n t e g e r • 2 : 

No C-Spec balancing errors on this diagram. 

No i l o f e ■ l o * f lo w constituent errors on this diagram. 

No syntax errors on this diagram. 

P-Spec: 2 . 3. l;4 ‘ASP Accelerometer Expand Data Flows 

No syntax errors In the I/O list. 

P-Spec: 2.3.2:21 'ASP Accelerometer Sensor Process1ng(P-Spec 2.1.1)* 

No syntax errors In the I/O list. 


P-Spec: 2. 3. 3:3 'ASP Accelerometer Compress Data Flows' 

No syntax errors in the I/O list. 
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Report # Pluto PR #1.0 


Notes/Explanation (Please reference appropriate section number): 


DFD: 1.4:16 'CP • CokiiiiIciiIoii Procei«ln| Dali Eapand and CtnprMi' 

Bubble*: 

230 Rubble 2 *CP-Communlcatlons Processing' does not milch Ihe child P-Spec 

t I I t e 'CP*Communle«tlofii P r o c e M I n | ( T • S p e f 2.4)*. 

Flows: 


2 3 7 

•AE.SWITCII' It 

2 3 8 

'BYTE .PACKET' 

2 3 9 

’CHECKSUM' In 

2 4 0 

’CL' from off p 
connector. 

2 4 1 

*C. STATUS' Int 

2 4 2 

* F R AME.BEAM. 

2 4 3 

'FRAME.ENOIN 

2 4 4 

•INTERN AL.CM 

2 4 5 

'ITII.FR A M E . 2 1 

2 4 8 

•IT II. FRAME. 5 

2 4 7 

' N B Y T E S ' out c 

8 

•RE.SWITCII* 1 

d49 

•TDLRSP.SWIT 

2 5 0 

'TDSP.SWtTCH 

2 5 1 

•TE.LIMIT’ lot 

2 5 2 

•THETA' Into b 

2 5 3 

The control f 1 
data flow. 

2 5 4 

The data flow 


A comment Is not terminated on line I resdlng ***: 

• I n I c |«r • J • 

No C-Spec balancing errors on this diagram. 

No store-to-flow constituent errors on this diagram. 

P-Spec: 2 . 4 . I ; 3 'CP Communications Processing Expand Data Flows' 

No syntax errors In the I/O list. 

P-Spec: 2 . 4 . 2 * i J 'CP Communications Processlng(P-Spec 2.4)' 

No syntax errors In the I/O list. 

P-Spec: 2 . 4 . 3 : 5 'CP Communications Processing Compress Data Flows* 

No syntax errors In the I/O list. 

P-Spec: 2 . 4 . 4 ; 3 'CP Communications Processing Expand OUIDANCE.STATE Data 

Store' 

No syntax errors In the I/O list. 

P-Spec: 2.4.5:* 'CALCULATE CRC-16* 

No syntax errors In the I/O list. 


DFD: 2.5:3 * C R C P Chute Release Control Processing' 

Bubbles: 
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a. Report # Pluto PR #1. 


b. Notcs/Explanation (Please reference appropriate section number): 

255 Bubble 2 'C R C P - C h u Ic Release Control Processing' does not match the child P ■ 
Spec title *CRCP*Chule Release Control Processlng(P-Spec 2.3.3)*. 

Flows: 

256 The control flow 'CIIUTE.RELEASED' Is defined In the Data Dictionary as a 
data flow. 
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Dubb 

1 e 

2 ' 0 P • O u 1 

d ■ n c 

e r 

0 

a 1 

1 d • n 

it e Pi 

0 

c e s s 1 n g ( P - 

Spec 

2 . 


'CL' 

connector. 

from off page 

1 0 

o f f 

p * 

ge Is nol connected 

to a bubble or C-Spec 

'CL' 

Into child P-S 

P e 

c 2 . 

7 . 

2 

Is unmatched. 


•CL' 

out of child P 

• S 

pec 

2 

. 7 

.2 Is unmatched. 



'E N D_ OC S ' out of bubble 2 Is unmatched. 

'MAX.NORMAl.VF. LOCITY' Into child P-Spec 2.7.2 li unmatched. 
•MAX NORMAL. VELOCITY' out of bubble 1 Is unmatched. 
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Report #: Pluto PR #1.0 


. . Notes/Explanation (Please reference appropriate section number): 
2 8 9 
2 7 0 


'TE.INTEORAL' from off page to off page la not connected to • bubble or C - 
Spec connector. 

'TE .INTEGRAL* out of child P-Spec 2.7.2 Is unmatched. 


No C-Spec balancing errors on this diagram. 

No DDE errors on this diagram. 

No store-to-flow constituent errors on this diagram. 

P • S p e t : 2. 7. 1:3 'OP Guidance Processing Data Expand' 

No syntax errors In the I/O list. 

P - S p c c : 2.7.2:29 ’OP Guidance Procc**lng(P-Spec 2.2)' 

No syntax errors In the I/O list. 

P-Spec: 2 . 7 . 3 : 4 ' O P Guidance Processing Data Compress' 

No syntax errors In the I/O tlst. 


D F D : 2 . R : 4 ' R E C L P Roll Engine Control Law Processing* 

Rubbles: 

271 Ilubble 2 ' R F, C L P • R o I I Engine Control Law Processing* does not match the child 
P-Spec title •RECLP-Roll Engine Control I. aw Processlng(P-Spec 2.3.2)*. 

Flows; 

272 ’DELTA.T* from off page to off page Is not connected to a bubble • r C * S p e e 
connector. 


2 7 3 
2 7 4 


'DELTA.T* Into child P-Spec 2 . R . 2 Is unmatched. 
’RE. STATUS' Into bubble 2 Is unmatched. 


No C-Spec balancing errors on this diagram. 

No DDE errors on this diagram. 

No store-to-flow constituent errors on this diagram. 

P-Spec: 2 . R . I : 1 'RECLP Roll Engine Control Law Processing Data Expand* 
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Engine Control 

Law Processing Data Compress 


No syntax errors In the I/O list. 

DPD: 2.9:4 ' T D L R S P Touch Down I. andlng Radar Sensor Troc. Data Exp. & Comp.* 

Bubbles: 

275 Bubble 2 'TDLR SP-Touch Down Landing Radar Sensor Processing* does not 
match the child P-Spec title *TDLRSP-Touch Down Landing Radar Senior 
Processlng(P-Spec 2.1.3*. 

Plows: 

276 'TDLR.STATUS* Into bubble 2 Is unmatched. 

277 The data flow 'TDLR.COUNTER* has an Invalid definition. 

A comment Is not terminated on line 5 reading * • * : 

DATA TYPE: a r r a y ( 1 . . 4 ) of I n t e |« r ' J : 

No C-Spec balancing errors on this diagram. 

No store-to-flow constituent errors on this diagram. 

No syntax errors on this diagram. 

P-Spec: 2. 9. 1:4 'TDLR S P Touch Down Landing Radar Sensor Processing Data 

Expand’ 

No syntax errors In the I/O list. 


P-Spec: 2.9.2:17 'TDLRSP Touch Down Landing Radar Sensor Procetslng(P-Spec 

2.1.3’ 

No syntax errors In the I/O list. 
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Problem Report Continuation 



b. Notes/Explanation (Please reference appropriate section number): 

P-Spec: ' T D L R S P - Touch Down Landing Radar Data Comp' 

No aynlaa errors In (he I/O Mil. 

P Spec: 3:3 'GENERATE _SEQUENCE_PARMS' 

No syntax errors In the I/O list. 

Checking completed. 
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GCS Action Report 


1. AR ft: i I “ 

2. Planet: 


3. Date of Action: 


page l ot ±y 

4. Respondent & Role: 


Pluto 




Carter, P. Programmer 

5. Artifact Identification: 





Design Description 
__ Source Code 

Executable Object Code 

Support Documentation 

Other 

Configuration Item: 

Pluto Design Description 


6. Description of Action 


(*) DFD: Context-Diagram : 12 'GCS'. • 

(1) Data Flow " INITIALIZATION_DATA" has an invalid definition. 
<Action> Removed '+' from ' A_ACCELERATION' . 

(2) Data Flow "PACKET" has an invalid definition. 

<Action> Changed '*' to a '-' in data type definition. 

(*) DFD: 0:17 ' INIT_RUN_GCS' . 

(3) Control Flow "INIT_DONE" has an invalid definition. 

<Action> Removed ';' from ' INIT_DONE' . 

(4) Control Flow "RUN_DONE" has an invalid definition. 

<Action> Changed '*' to a '-' in data type definition. 

(5) Data Flow "FRAME_COUNTER" has an invalid definition. 

<Action> Changed '*' to a ' -' in data type definition. 

(*) PAT 0-sl : 13 ' INIT_RUN_GCS PAT'. 

(6) DDE "INIT_DONE" has an invalid definition. 

<Act ion> Removed ';' from ' INIT_DONE' . 

(7) DDE "RUN_DONE" has an invalid definition. 

<Action> Changed ' *' to a in data type definition. 

(*) DFD: 2:51 'RUN_GCS'. 

(8) Bubble 1 "AECLP" doesn't match child bubble (Axial Engine Data 
Expand and Compress) . 

<Action> Renamed bubble 1 and child to "AECLP". 

(9) Bubble 10 "TDSP" doesn't match child bubble (Touch Down Sensor 
Processing Data Expand and Compress) . 

<Action> Renamed bubble 10 and child to "TDSP". 

(10) Bubble 11 "TSP" doesn't match child bubble (Temperature Sensor 
Processing Expand and Compress) . 

<Action> Renamed bubble 11 and child to "TSP". 

(11) Bubble 2 "ARSP" doesn't match child bubble (Altimeter Radar Data 
Expand and Compress) . 

<Act ion> Renamed bubble 2 and child to "ARSP". 


7. Was tire action related to another action(s)? Yes AR#(s) 

I don’t know 
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Ac tion _ Report Continuation 


pageo^ of 1? 

•’.Report#: 


b. Notes/Explanation (Please reference appropriate section number): 


(12) Bubble 3 "ASP" doesn't match child bubble (Accelerometer 
Data Expand and Compress) . 

<Action> Renamed bubble 3 and child to "ASP". 

(13) Bubble 4 "CP" doesn't match child bubble (Communications 

Processing Data Expand and Compress) . * 

<Action> Renamed bubble 4 and child to "CP". 

(14) Bubble 6 "GSP" doesn't match child bubble (Gyroscope Sensor . 
Processing Data Expand and Compress) . 

<Action> Renamed bubble 6 and child to "GSP". 

(15) Bubble 7 "GP" doesn't match child bubble (Guidance Processing 
Data Expand and Compress) . 

<Action> Renamed bubble 7 and child to "GP" . 

(16) Bubble 8 "RECLP" doesn't match child bubble (Roll Engine 
Control Law Processing) . 

<Action> Renamed bubble 8 and child to "RECLP" . 

(17) Bubble 9 "TDLRSP" doesn't match child bubble (Touch Down 
.Landing Radar Sensor Proc.Data Exp.&Comp). 

<Action> Renamed bubble 9 and child to "TDLRSP". 

(18) P-Spec:2.12 exists, but bubble 12 missing. 

<Action> Created bubble 12. 

(19) Data Flow "ACCEL_GS_IN" is not a constituent of store 
' GUIDANCE_STATE' . 

<Action> Created the Data Store " GU I DANCE_S TATE " . 

(20) Data Flow "ACCEL_GS_OUT" is not a constituent of store 
' GUIDANCE_STATE' . 

<Action> Created the Data Store " GU I DANCE_S TATE " . 

(21) Data Flow "ACCEL_RP_IN" is not a constituent of store 
' RUN_PARAMETERS' . 

<Act ion> Created the Data Store "RUN_PARAMETERS" . 

(22) Data Flow "ACCEL_SO_IN" is not a constituent of ?tore 
' SENSOR_OUTPUT' . 

<Act ion> Created the Data Store "SENSOR_OUTPUT" .. 

(23) Data Flow "ACCEL_SO_OUT" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Action> Created the Data Store "SENSOR OUTPUT" . 


I 
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page 3. of A? 

a. Report #: /. | 

b. Notes/Explanation (Please reference appropriate section number): 


(24) DDE "AE_CMD" has an invalid definition. 

<Action> Changed to a in data type definition. 

(25) DDE "AE_STATUS" has an invalid definition. 

<Act ion> Changed to a in data type definition. 

(26) DDE "AE_SWITCH" has an invalid definition. 

<Act ion> Changed '*' to a in data type definition. 

(27) DDE "AE_TEMP" has an invalid definition. 

<Action> Changed '*' to a ' -' in data type definition. 

(28) DDE "ALP H A_MAT R I X " has an invalid definition. 

<Act ion> Changed ' *' to a ' in data type definition. 

(29) Data Flow "ALT_RAD_GS__IN" is not a. constituent of the store 
'GUIDANCE_STATE' . 

<Action> Created the Data Store "GUI DAN C E_S TAT E " . 

(30) Data Flow "ALT_RAD_GS_OUT" is not a constituent of the store 
'GUIDANCE_STATE' . 

<Act ion> Created the Data Store "GUIDANCE_STATE" . 

(31) .Data Flow "ALT_RAD_RP_IN" is not a constituent of the store 

' RUN_PARAMETERS' . 

<Act ion> Created the Data Store RUN_PARAMETERS" . 

(32) Data Flow "ALT_RAD_SO_IN" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Action> Created the Data Store "SENSOR_OUTPUT" . 

(33) Data Flow "ALT_RAD_SO_OUT" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Action> Created the Data Store "SENSOR_OUTPUT" . 

(34) DDE " AR_ALT I TUDE " has an invalid definition. 

<Action> Changed ' *' to a in data type definition. 

(35) DDE "AR_COUNTER" has an invalid definition. 

<Action> Changed '*' to a ' in data type definition. 

(36) DDE "AR_FREQUENCY" has an invalid definition. 

<Action> Changed '*' to a in data type definition. 

(37) DDE "AR_STATUS" has an invalid definition.. 

<Act ion> Changed to a in data type definition. 

(38) DDE " ATMOSPHERE I C_TEMP" is undefined. 

<Act ion> Corrected misspelling of 'ATMOSPHERIC TEMP' . 


I 
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a. Report#: (. | 


b. Notes/Explanation (Please reference appropriate section number): 


(39) DDE "ATMOSPHERIC_TEMP" has an invalid definition. 

<Action> Changed to a in data type definition. 

(40) Data Flow "AX_ENG_GS_IN" is not a constituent of the store 

'GUIDANCE_STATE' . • 

<Act ion> Created the Data Store "GUIDANCE_STATE" . 

(41) Data Flow "AX_ENG_GS_OUT" is not a constituent of the store 
f GUIDANCE_STATE' . 

<Action> Created the Data Store " GU I D ANCE_S T ATE " . 

(42) Data Flow "AX_ENG_RP_IN" is not a constituent of the store 
'RUN_PARAMETERS' . 

<Action> Created the Data Store "RUN_PARAMETERS" . 

(43) Data Flow "AX_ENG_J30_IN" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Act ion> Created the Data Store "SENSOR_OUTPUT" . 

(44) DDE "A_ACCELERATION" has an invalid definition. 

.<Action> Changed ’ *’ to a in data type definition. 

(45) DDE "A_BIAS" has an invalid definition. 

<Action> Changed to a in data type definition. 

(46) DDE "A_GAIN" has an invalid definition. 

<Action> Changed ' to a ' in data type definition. 

(47) DDE "A_SCALE" has an invalid definition. 

<Action> Changed to a in data type definition. 

(48) DDE "A_STATUS " has an invalid definition. 

<Action> Changed to a in data type definition. 

(49) Control Flow "CHUTE_RELEASE" is not a constituent of the store 
' GUIDANCE_STATE' . 

<Act ion> Created the Data Store "GUIDANCE_STATE" . 

(50) DDE "CHUTE_RELEASED" has an invalid definition. 

<Action> Changed to a in data type definition. 

(51) Data Flow "CHUTE_REL_GS_IN" is not a constituent of the store 
' GUIDANCE_STATE' . 

<Act ion> Created the Data Store "GUIDANCE STATE". 


I 
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b. Notes/Explanation (Please reference appropriate section number): 


(52) Data Flow "CHUTE_REL_GS_OUT" is not a constituent of the store 
' GUI DANCE_S TATE' . 

<Action> Created the Data Store "GUIDANCE_STATE" . 

(53) DDE "CL" has an invalid definition. 

<Action> Changed '*' to a '-' in data type definitiori. 

(54) Data Flow "CL" is unmatched out of DFD 2.4. 

<Action> Added 'CL' to the output list of P-Spec 2.4.4. 

(55) Data Flow "CL" is unmatched out of DFD 2.7. 

<Action> Added 'CL' to the output list of P-Spec 2.7.1. 

(56) Data Flow "COMM_GS_IN" is not- a constituent of the store 
' GUIDANCE_STATE' . 

<Act ion> Created the Data Store "GUIDANCE_STATE" . 

(57) Data Flow "COMM_GS_OUT" is not a constituent of the store 
' GUIDANCE_STATE' . 

<Act ion> Created the Data Store "GUIDANCE_STATE" . 

(58) Data Flow "COMM_RP__IN" is not a constituent of the store 
. ' RUN_P ARAMETERS ' . 

<Act ion> Created the Data Store " RUN_P ARAMETERS " . 

(59) Data Flow "COMM_SO_IN" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Action> Created the Data Store "SENSOR_OUTPUT" . 

(60) DDE " C OMM_S Y N C_P AT T E RN " has an invalid definition. 

<Action> Changed '*' to a '-' in data type definition. 

(61) DDE " CONTOUR_ALT I TUDE " has an invalid definition. 

<Action> Changed ' *' to a ' -' in data type definition. 

(62) DDE "CONTOUR_CROSSED" has an invalid definition. 

<Action> Changed '*' to a ' -' in data type definition. 

(63) DDE " CONTOUR_VELOC I T Y " has an invalid definition. 

<Action> Changed ' *' to a '-' in data type definitiori. 

(64) DDE "C_STATUS" has an invalid definition. 

<Action> Changed '*' to a '-' in data type definition. 

(65) DDE "DELTA_T" has an invalid definition. 

<Action> Changed '*' to a ' -' in data type definition. 

(66) Data Flow "DELTA_T" is unmatched out of DFD 2.8. 

<Action> Added 'DELTA_T' to the output list of P-Spec 2.8.1. 


I 
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b. Notes/Explanation (Please reference appropriate section number): 


(67) DDE " DROP_HE I GHT " has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(68) DDE "DROP_SPEED" has an invalid definition. 

<Action> Changed to a in data type definition. 

(69) "ENGINES_OFF" is undefined. 

<Action> Unnecessary variable deleted from file. 

(70) DDE "ENGINES_ON_ALTITUDE" has an invalid definition. 

<Action> Changed to a in data type definition. 

(71) DDE "FRAME_BEAM_UNLOCKED" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(72) Data Flow " FRAME_COUNTER" is unmatched out of DFD 2.2. 

<Action > Added ' FRAME_COUNTER' to the output list of 
P-Spec 2.2.1. 

(73) DDE "FRAME_ENGINES_IGNITED" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(74) .DDE " FULL_UP_T IME " has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(75) DDE "GA" has an invalid definition. 

<Action> Changed ' to a in data type definition. 

(76) DDE "GAX" has an invalid definition. 

<Action> Changed to a in data type definition. 

(77) DDE "GPY" has an invalid definition. 

<Action> Changed to a in data type definition. 

(78) DDE "GP1" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(79) DDE "GP2" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(80) DDE " GP_ALT I TUDE " has an invalid definition. 

<Action> Changed to a in data type definition. 

(81) DDE "GP_ATTITUDE" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(82) Data Flow "GP^ATTITUDE" is unmatched out of DFD 2.1. 

<Act ion> Added " GP_ATT I TUDE " to the output list of P-Spec 2.1. 

(83) DDE " GP_PHASE" has an invalid definition. 

<Action> Changed to a in data type definition. 

(84) DDE "GP_ROTATION" has an invalid definition. 

<Action> Changed to a in data type definition. 
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(85) DDE "GP_VELOCITY" has an invalid definition. 

<Action> Changed to a in data type definition. 

(86) DDE "GQ" has an invalid definition. 

<Action> Changed to a in data type definitiori. 

(87) DDE "GR" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(88) DDE "GRAVITY" has an invalid definition: 

<Action> Changed to a in data type definition. 

(89) Data Flow "GUIDE_GS_IN" is not a constituent of the store 

' GUI DANCE_S TATE' . 

<Action> Created the Data Store "GUI DANCE_ST ATE " . 

(90) Data Flow "GUIDE_GS_OUT" is not a constituent of the store 
'GUIDANCE_STATE' . 

<Act ion> Created the Data Store "GUI DANCE_S TATE " . 

(91) Data Flow "GUIDE_RP_IN" is not a constituent of the store 
.'RUNJPARAMETERS' . 

<Action> Created the Data Store "RUN_PARAMETERS" . 

(92) Data Flow "GUIDE_SO_IN" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Action> Created the Data Store "SENSOR_OUTPUT" . 

(93) DDE "GV" has an invalid definition. 

<Action> Changed to a in data type definition. 

(94) DDE "GVE" has an invalid definition. 

<Action> Changed to a ’ in data type definition. 

(95) DDE "GVEI" has an invalid definition. 

<Action> Changed to a ’ in data type definition. 

(96) DDE "GW" has an invalid definition. 

<Action> Changed to a ’ in data type definition. 

(97) DDE "GWI" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(98) Data Flow "GYRO_GS_IN" is not a constituent of the store 
'GUIDANCE_STATE' . 

<Action> Created the Data Store "GUIDANCE STATE". 


I 
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(99) Data Flow "GYRO_GS_OUT" is not a constituent of the store 
' GUI DANCE_S TATE' . 

<Action> Created the Data Store "GUIDANCE_STATE" . 

(100) Data Flow "GYRO_RP_IN" is not a constituent of the store 

' RUN_PARAMETERS ' . ' 

<Action> Created the Data Store "RUN_PARAMETERS" . 

(101) Data Flow "GYRO_SO_IN" is not a constituent of the store 
• SENSOR_OUTPUT' . 

<Action> Created the Data Store "SENSOR_OUTPUT" . 

(102) Data Flow "GYRO_SO_OUT" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Action> Created the Data Store "SENSOR_OUTPUT" . 

(103) DDE "Gl" has an invalid definition. 

<Action> Changed ' *' to a in data type definition. 

(104) DDE "G2" has an invalid definition. 

<Action> Changed ' *' to a ' in data type definition. 

(105) .DDE "G3" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(106) DDE "G4" has an invalid definition. 

<Action> Changed to a in data type definition. 

(107) DDE "G_GAIN_0" has an invalid definition. 

<Action> Changed to a in data type definition. 

(108) DDE "G_OFFSET" has an invalid definition. 

<Action> Changed to a in data type definition: 

(109) DDE " G_R0TAT I ON " has an invalid definition. 

<Action> Changed f * r to a ' in data type definition. 

(110) DDE "G_STATUS" has an invalid definition. 

<Action> Changed to a in data type definition. 

(111) Data Flow " INIT_GS_OUT" is not a constituent of the store 

'GUIDANCE_STATE' . 

<Action> Created the Data Store "GUIDANCE_STATE" . 

(112) Data Flow " INIT_RP_OUT" is not a constituent of the store 
' RUN_PARAMETERS ' . 

<Action> Created the Data Store "RUN PARAMETERS". 
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(113) DDE " INTERNAL_CMD" has an invalid definition. 

<Action> Changed to a in data type definition. 

(114) DDE "K_ALT" has an invalid definition. 

<Action> Changed to a in data type definition. 

(115) DDE "K_MATRIX" has an invalid definition. 

<Action> Changed ' to a ' in data type definition. 

(116) DDE "MAX_NORMAL_VELOCITY" has an invalid definition. 

<Action> Changed to a in data type definition. 

(117) Data Flow ,, MAX_NORMAL_VELOCITY" is unmatched out of DFD 2.7. 
<Action> Added ' MAX_NORMAL_VELOCITY' to the output list of 
P-Spec 2.7.1. 

(118) DDE "Ml" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(119) DDE "M2" has an invalid definition. 

<Action> Changed to a in data type definition. 

(120) DDE "M3" has an invalid definition. 

<Action> Changed ' *' to a ' in data type definition. 

(121) .DDE "M4 " has an invalid definition. 

<Act ion> Changed to a ' in data type definition. 

(122) DDE "OMEGA" has an invalid definition. 

<Action> Changed to a in data type definition. 

(123) DDE "PE_INTEGRAL" has an invalid definition. 

<Action> Changed to a in data type definition. 

(124) DDE "PE_MAX" has an invalid definition. 

<Action> Changed to a in data type definition. 

(125) DDE "PE_MIN" has an invalid definition. 

<Act ion> Changed to a in data type definition. 

(126) DDE "PI" has an invalid definition. 

<Action> Changed to a in data type definition. 

(127) DDE "P2" has an invalid definition. 

<Action> Changed ' *' to a in data type definition. 

(128) DDE "P3" has an invalid definition. 

<Act ion> Changed ' *' to a in data type definition. 

(129) DDE "P4" has an invalid definition. 

<Action> Changed ' *' to a in data type definition. 

(130) DDE " RE_CMD " has an invalid definition. 

<Act ion> Changed to a ' in data type definition. 

(131) DDE " RE_S T AT US" has an invalid definition. 

<Act ion> Changed ' *' to a ' in data type definition. 

(132) DDE "RE_SWITCH" has an invalid definition. 

<Action> Changed ' ’ ' . a in data type definition. 
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(133) Data Flow "ROL_ENG_GS_IN" is not a constituent of the store 
'GUIDANCE_STATE' . 

<Action> Created the Data Store GUIDANCE_STATE" . 

(134) Data Flow "ROL_ENG_GS_OUT" is not a constituent of the store 

'GUIDANCE_STATE' . • 

<Action> Created the Data Store "GUIDANCE_STATE" . 

(135) Data Flow "ROL_ENG_RP_IN" is not a constituent of the store 
' RUN_P ARAMETERS ' . 

<Act ion> Created the Data Store "RUN_PARAMETERS" . 

(136) Data Flow "ROL_ENG_SO_IN" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Action> Created the Data Store "SENSOR_OUTPUT" . 

(137) DDE "TDLRSP_S WITCH" is undefined. 

<Action> Defined this variable in the Data Dictionary. 

(138) DDE "TDLR_ANGLES" has an invalid definition. 

<Action> Changed to a in data type definition. 

(139) .DDE "TDLR_GAIN" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(140) DDE " TDLR_LOCK_T IHE " has an invalid definition. 

<Action> Changed to a in data type definition. 

(141) DDE "TDLR_OFFSET" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(142) DDE "TDLR_STATE" has an invalid definition. 

<Action> Changed ' *' to a ' in data type definition. 

(143) DDE "TDLR_STATUS" has an invalid definition. 

<Action> Changed ' *' to a in data type definition. 

(144) DDE "TDLR_VELOCITY" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(145) DDE "TDSP_S WITCH" is undefined. 

<Action> Defined the variable in the Data Dictionary. 

(146) DDE "TDS_STATUS" has an invalid definition. 

<Action> Changed to a ' in data type definition. 

(147) Data Flow "TD_GS_IN" is not a constituent of the store 
'GUIDANCE_STATE' . 

<Action> Created the Data Store "GUIDANCE STATE" . 
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(148) Data Flow "TD_GS_OUT" is not a constituent of the store 
'GUIDANCE_STATE' . 

<Action> Created the Data Store "GUIDANCE_STATE" . 

(149) Data Flow "TD_LHD_RAD_GS_IN" is not a constituent of' the store 
'GUIDANCE_STATE' . 

<Action> Created the Data Store "GUIDANCE_STATE" . 

(150) Data Flow "TD_LND_RAD_GS_OUT" is not a constituent of the store 
'GUIDANCE_STATE' . 

<Act ion> Created the Data Store "GUIDANCE_STATE" . 

(151) Data Flow "TD_LND_RAD_RP_IN" is not a constituent of the store 
'RUN_PARAMETERS' . 

<Action> Created the Data Store "RUN_PARAMETERS" . 

(152) Data Flow "TD_LND_RAD_SO_IN" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Act ion> Created the Data Store "SENSOR_OUTPUT" . 

(153) .Data Flow "TD_LND_RAD_SO_OUT" is not a constituent of the store 

' SENSOR_OUTPUT' . 

<Action> Created the Data Store "SENSOR_OUTPUT" . 

(154) DDE "TD_SENSED" has an invalid definition. 

<Action> Changed to a in data type definition. 

(155) Data Flow "TD_SO_OUT" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Act ion> Created the Data Store "SENSOR_OUTPUT" . 

(156) Data Flow "TEMP_GS_IN" is not a constituent of the store 
' GUI DANCE_S TATE' . 

<Action> Created the Data store "GUIDANCE_STATE" . 

(157) Data Flow , 'TEMP_GS_OUT" is not a constituent of the store 
' GUIDANCE_STATE' . 

<Action> Created the Data Store "GUI D ANCE_S TAT E " # . 
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(158) 


(159) 


(160) 

(161) 

(162) 

(163) 

(164) 

(165) 

(166) 

(167) 

(168) 

(169) 

(170) 

(171) 

(172) 


(173) 


Data Flow "TEMP_RP_IN" is not a constituent of the store 
' RUN_PARAMETERS' . 

<Action> Created the Data Store "RUN_PARAMETERS" 

Data Flow "TEMP_SO_OUT" is not a constituent of the store 
' SENSOR_OUTPUT' . 

<Action> Created the Data Store "SENSOR OUTPUT" . 

DDE 'TE DROP" has an invalid definition! 

<Act ion> Changed to a ' in data type definition. 

DDE TE INIT" has an invalid -definition. 

™ t i° n> Changed to a in data type definition. 

DDE TE_INTEGRAL" has an invalid definition 

<Act ion> Changed to a ' in data type definition. 

Data Flow "TE_INTEGRAL" is unmatched out of DFD 2 7 
<Action> Added ' TE_INTEGRAL' to the input list ofVspec 2 7 3 
DDE ,, TE_LIMIT" has an invalid definition. • 

■<Action> Changed to a ' in data type definition. 

DDE "TE_MAX " has an invalid definition. 

Changed to a in data type definition. 

DDE TE_MIN" has an invalid definition. 

<Acti° n> Changed ' *' to a 'V in data type definition. 

DDE "THETA" has an invalid definition. 

<Action> Changed to a in data type definition. 

DDE THETA1" has an invalid definition. 

<Act ion> Changed to a in data type definition 

DDE "THETA2 " has an invalid definition. 

™ t i° n> changed to a in data type definition. 

DDE TS STATUS" has an invalid definition. 

<Act ion> Changed to a in data type definition 

DDE "Tl" has an invalid definition. 

<^ti°n> Changed to a in data type definition. 

DDE "T2" has an invalid definition. 

<Act ion> Change ' to a ' ih data type definition. 

DDE " T 3 " has invalid definition. 

<Action> Changed to a in data type definition. 
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(174) DDE "T4" has an invalid definition. 

<Action> Changed to a in data type definition. 

(175) DDE "VELOCITY_ERROR" has an invalid definition. 

<Action> Changed '*' to a ' in data type definitiori. 

(176) DDE "YE_INTEGRAL" has an invalid definition. 

<Act ion> Changed to a in data type definition. 

(177) DDE "YE_MAX" has an invalid definition. 

<Action> Changed to a in data type definition. 

(178) DDE " YE_MIN" has an invalid definition. 

<Action> Changed '*' to a ' -' in data type definition. 

(179) DDE "SUBFRAME_COUNTER" has an invalid definition. 

<Act ion> Changed '.*' to a in data type definition. 

(180) Control Flow "SUBFRAME_COUNTER" defined as a data flow. 

<Action> Changed ' SUBFRAME_COUNTER' to a control flow in DD . 

(181) Store "GUI DANCE_S TATE " defined as a flow. 

•<Act ion> Created the Data Store "GUIDANCE_STATE" . 

(182) Store " GU I DANCE_S TATE " is undefined. 

<Act ion> Created the Data Store "GUIDANCE_STATE" . 

(183) Store " RUN_PARAMETERS " defined as a flow. 

<Action> Created the Data Store "RUN_PARAMETERS" . 

(184) Store "RUN_PARAMETERS" is undefined. 

<Act ion> Created the Data Store "RUN_PARAMETERS" . 

(185) Store "SENSOR_OUTPUT" is defined as a flow. 

<Action> Created the Data Store "SENSOR_OUTPUT" . 

(186) Store "SENSOR_OUTPUT" is undefined. ~ 

<Action> Created the Data Store "SENSOR_OUTPUT" . 

(*) PAT 2-sl : 13 'PAT - CONTROL ORDER OF EXECUTION OF MODULES IN RUN_GC 5' 

(187) Column 1, "F" 'Not a constituent of DDE " ITH_FRAME_2 " ' . 

<Act ion> Renamed 'F' to 'FALSE' in PAT. 

(188) Column 1, DDE 'F' is not a discrete element. 

<Action> Renamed 'F' to 'FALSE' in PAT. 

(189) Column 1 , DDE. "ITH_FRAME_2" is’ not a discrete element. 

<Action> Modified the data element type attribute to "discrete'. 

(190.) Column 2, "F" 'Not a constituent of DDE "ITH_FRAME 5"' . 

<Act ion> Renamed 'F' to 'FALSE' in <&£&/ ~ 

pat 
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(191) Column 2, DDE "F" is not a discrete element. 

<Action> Deleted this entry in the Data Dictionary. 

(192) Column 2, DDE "ITH_FRAME_5" is not a discrete element. 

<Action> Modified the data element type attribute to ' "discrete' . 

(193) Column 3, DDE "RENDEZVOUS_CNTL" is not a discrete element. 

<Act ion> Modified the data element type, attribute to "discrete' . 

(194) Column 4, "F" is not a constituent of DDE 'END_GCS'. 

<Action> Renamed 'F' to ' FALSE' in p^t^ 

(195) Column 4, DDE "END_GCS" is not a discrete element. 

<Action> Modified the data element, type attribute to "discrete' . 

(196) Column 4, DDE "F" is not a discrete element. 

<Action> Deleted this entry in the Data Dictionary. 

(197) Column 5, "F" is not a constituent of DDE ' GP_HAS_RUN' . 

<Action> Renamed ' F' to ' FALSE' in V&T 

(198) Column 5, DDE "F" is not a discrete element. 

<Act ion> Deleted this entry in the Data Dictionary. 

(199) DDE "SUBFRAME_COUNTER" has an invalid definition/ 

<Action> Changed '*' to a '-' in data type definition. 

(200) DDE ' SUBFRAME__COUNTER" is neither control or data flow. 

<Action> Made ' SUBFRAME_COUNTER' a control flow in DD . 

(201) DDE "RUN_DONE" has an invalid definition. 

<Action> Changed to a in data type definition. 

(202) Column 23, DDE "RENDEZVOUS_CNTL" is not a discrete element. 

<Act ion> Modified the data element type attribute to "discrete’. 

(203) Column 24, "F" is not a constituent of DDE ' GP_HAS_RUN' . 

<Act ion> Renamed 'F' to 'FALSE' in 

(204) Column 24, DDE "F" is not a discrete element. 

<Action> Renamed 'F' to 'FALSE' in p^: 

(205) DDE "SUBFRAME_COUNTER" has an invalid definition.. 

<Action> Changed '*' to a '-' in data type definition. 

(206) DDE "SUBFRAME_COUNTER" is neither control or data flow. 

<Act ion> Made ' SUBFRAME_COUNTER' a control flow in DD . 

(*) DFD 2.1:10 ' AECLP ' . 

(207) DFD 2.1 bubble 2 (Axial Engine Control Law Processing) 

doesn't match P-Spec 2.1.2 title. 'YIEolP - 

<Action> Modified P-Spec 2.1.2 title to (Axial Engine ' Control 
Law Processingf. 


I 


E-33 



Ac tion Report Continuation 


page 


I Oof 19 


^.Report#: j j 


b. Notes/Explanation (Please reference appropriate section number): 


(208) 


(209) 


( 210 ) 


( 211 ) 


( 212 ) 


,2 is 
data 


2 . 1.2 


unmatched . 
flow GP ATTITUDE 


Data Flow "AE_STATUS" is unmatched out of P-Spec 2.1.1 
<Action> Added 'AE_STATUS' to the input list of P-Spec 
Data Flow "CL" out of DFD 2.1 bubble 1 is unmatched. 

<Action> Modified DFD 2.1 redrawing the data flow CL 
between DFD 2.1.1 and DFD 2.2.2. 

Data Flow "GP_ATTITUDE" INTO P-Spec 2.1 
<Action> Modified DFD 2.1 redrawing the _ 

between 2.1.1 AND 2.1.2. 

Data Flow "GP_ATTITUDE" out of DFD 2.1 bubble 1 is unmatched. 
<Action> Modified DFD 2.1 redrawing the data flow GP_ATTITUDE 
between DFD 2 . 1 bubble 1 and DFD 2 . 1 bubble 2 . 

Data Flow "GRAVITY" out of DFD 2.1 bubble 1 is unmatched. 

<Act ion> Added 'GRAVITY' to the output list of P-Spec 2.1.1. 
DDE "GVI" has an invalid definition. 


/ */ 


(*) 


(213) 

<Action> Changed 
DFD 2.10:5 'TDSP' . 

(214) DFD 2.10 bubble 1 LTouch 
. P-Spec 2.10.1 title. 

<Action> Modified P-Spec 
Data Flows) . 

(215) DFD 2.10 bubble 2 (Touch 
P-Spec 2.10.2 title. 
<Action> Modified P-Spec 
Processing) . 

(216) DFD 2.10 bubble 3 
match P-Spec 2.10 
<Action> Modified 
Data Flows) . 

(217) DDE "TD_COUNTER" has 

i. * / 


r _ / 


to a 
TO^P ~ 

Down 


in data type definition. 

Expand Data Flows) doesn't matclh 


2.10.1 title to (Touch Down Expand 
Down Sensor Processing) doesn't matcli 


2.10.2 title to 


T (751° - 
(Touch Down 
A 


Sensor 


(Touch Down 
3 title. 
P-Spec 2.10 


Compress Data Flows) doesn't 

7 Pl>P- 

^Touch Down Compres 


3 title to 


an invalid definition. 


t _ / 


in data type definition. 


<Action> Changed '*' to a 

(*) DFD 2.11:2 'TSP' . . 

(218) DFD 2.11 bubble 2 (Temperature Sensor Processing) doesn't mat 

P-Spec 2.11.2 title. TSp - 

<Action> Modified P-Spec 2.11.2 title to ^Temperature Sensor 
Processing) . 

(219) Data Flow "TS_STATUS" is unmatched into DFD 2.11. 

<Action> Added 'TS_STATUS' to the input list of P-Spec 2.11.1 

(220) DDE "SS_TEMP" has an invalid definition. 

<Action> Changed '*' to a '-' ih data type definition. 

(221) DDE "THERMO TEMP" has an invalid definition. 


bh 


<Action> Changed 


f * r 


to a 


t _ i 


in data type definition. 
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(*) P-Spec 2. 16; 3 "SEND CHUTE RELEASE COMMAND". 

(222) DDE "CHUTE_RELEASE" is an input control flow. 

<Action> Changed ' CHUTE_RELEASE' to a data flow. 

(*) P-Spec 2.18:8 "COPY CONTROL DATA". 

(223) I/O Entry: " INIT_END_GCS" is an input control flow. 

<Action> Changed ' INIT_END_GCS' to a data flow. 

(224) I/O Entry: " INIT_RENDEZVOUS_CNTL" is an input control flow. 
<Action> Changed ' INIT_RENDEZVOUS_CNTL' to a data flow. 

(225) I/O Entry: " INIT_SUBFRAME_COUNTER" is -an input control flow. 
<Action> Changed ' INIT_SUBFRAME_COUNTER' to a data flow. 

(226) I/O Entry: " RENDE Z VOU S_CNTL " is an input control flow. 

<Act ion> Changed ' RENDEZVOUS_CNTL' to a data flow. 

(*) DFD 2 . 2 ; 5 'ARSP' . 

(227) DFD 2.2 bubble 2 (Altimeter Radar Sensor Processing) doesn't 

match P-Spec 2.2.2 title. - 

<Action> Modified P-Spec 2.2.2 title to (Altimeter Radar 
Sensor Processing) . ^ 

(228) Data Flow "FRAME_COUNTER" into child P-Spec 2.2.2 is unmatchec 
- <Action> Added ' FRAME_COUNTER' to the output list of the P-Sp< 

2.2.1. 

(229) Data Flow "FRAME_COUNTER" is unmatched out of DFD 2.2 bubble 
<Act ion> Added ' FRAME_COUNTER' to the P-Spec 2.2.1 output lisi 

(230) Data Flow "K_ALT" into child P-Spec 2.2.2 is unmatched. 
<Action> Added 'K_ALT' to the output list of the P-Spec 2.2.1 

(231) Data Flow "K_ALT" is unmatched out of DFD 2.2 bubble 1. 
<Action> Added 'K_ALT' to the P-Spec 2.2.1 output list. 

(*)' DFD 2 . 3 ; 5 'ASP' . 

(232) DFD 2.3 bubble 2 (Accelerometer Sensor Processing) doesn't 

match P-Spec 2.3.2 title. _ /ISP ~~ 

<Action> Modified P-Spec 2.3.2 title to (Accelerometer Sensor 
Processing) . * 

(233) Data Flow "A_ACCELERATION" into child P-Spec 2.3-2 is unmatchi 
. <Action> Added ' A_ACCELERATION' to the input list of the P-Sp 

(234) Data Flow " A_ACCELERAT I ON " is unmatched into DFD 2.3 bubble 2 
<Act ion> Added ' A_ACCELERATION' to input list of P-Spec 2.3.2 

(235) DDE "A_COUNTER" has an invalid definition. 

<Action> Changed '*' to a '-' in data type definition. 

(*) DFD 2. 4; 16 'CP' . 

(236) DFD 2.4 bubble 2 (Communications Processing) doesn't match 

P-Spec 2.4.2 title. CP - 

<Action> Modified P-Spec 2.4.2 title to (Communications 
Processing) . * 


Sensor 


l 
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(*) DFD 2.4 'CP' . 

(237) Data Flow "AE_SWITCH" is unmatched into DFD 2.4 bubble 2. 
<Action> Added 'AE_SWITCH' to the input list of P-Spec 2.4.2. 

(238) Data Flow " B YTE_P ACKET " is unmatched out of DFD 2.4 bubble 2. 
<Act ion> Added ' BYTE_P ACKET' to the output list of P-Spec 2.4. 

(239) bata Flow "CHECKSUM" is unmatched into DFD 2.4 bubble 2. 
<Action> Added 'CHECKSUM' to the input list of P-Spec!: 2.4.2. 

(240) Data Flow "CL" not connected to a bubble or C-Spec connector. 
<Action> Redrew the flow so it connected DFD 2.4 bubble 2 and 
DFD 2.4 bubble 4. 

(241) Data Flow "C_STATUS" is unmatched into DFD 2.4 bubble 2. 
<Action> Added 'C_STATUS' to’ the input list of P-Spec 2.4.2. 

(242) Data Flow "FRAME_BEAM_UNLOCKED" is unmatched into DFD 2.4 
bubble 2 . 

<Act ion> Added ' FRAME_BEAM_UNLOCKED' to the input list of 
P-Spec 2.4.2. 

(243) Data Flow "FRAME_ENGINES_IGNITED" is unmatched into. DFD 2.4 
bubble 2 . 

■ <Action> Added ' FRAME_ENGINES_IGNITED' to the input list of 
P-SPec 2.4.2. 

(244) Data Flow " INTERNAL_CMD" is unmatched into DFD 2.4 bubble 2. 
<Action> Added ' INTERNAL_CMD' to the input list of P-Spec 2.4. 

(245) Data Flow " I TH_FRAME_2 " is unmatched into DFD 2.4 bubble 2. 
<Action> Added ' ITH_FRAME_2' to the input list of P-Spec 2.4.5 

(246) Data Flow " ITH_FRAME_5" is unmatched into DFD 2.4 bubble 2. 
<Action> Added ' ITH_FRAME_5' to the input list of P-Spec 2.4.; 

(247) Data Flow "NBYTES" is unmatched out of DFD 2.4 bubble 2. 
<Action> Added 'NBYTES' to the output list of P-SPec 2.4.2. 

(248) Data Flow "RE_SWITCH" is unmatched -into DFD 2.4 bubble 2. 
<Action> Added 'RE_SWITCH' to the input list of P-Spec 2.4.2. 

(249) Data Flow "TDLRSP_SWITCH" is unmatched into DFD 2.4 bubble 2. 
<Action> Added ' TDLRSP_SWITCH' to the input list of P-Spec 2.‘ 

(250) Data Flow "TDSP_SWITCH" is unmatched into DFD 2.4 bubble 2. 
<Action> Added ' TDSP_SWITCH' to the input list of P-Spec 2.4.: 

(251) Data Flow "TE_LIMIT" is unmatched into DFD 2.4 bubble 2. 

<Act ion> Added ' TE_LIMIT' to the input list of P-Spec 2.4.2. 

(252) Data Flow "THETA" is unmatched into DFD. 2.4 bubble 2. 

<Actiori> Added 'THETA' to the input list of P-Spec 2.4.2. 

(253) Control Flow " SUBFRAME_COUNTER" is defined as a data flow.. 
<Action> Changed ' SUBFRAME_COUNTER' to a control flow in DD . 

(254) DDE "CHECKSUM" has an invalid definition. 

' . :<Action> Changed '*' to a ' -' in data type definition. 


I 
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Ac tion . Report Continuation 


page 1 ^of 19 

| a. Report#: | ~~ ~ 

o. Notes/E.xplanation (Please reference appropriate section number): 

(*) DFD 2.3 'CRCP' . 

(255) DFD 2.3 bubble 2 (Chute Release Control Processing) doesn't 

match P-Spec 2.3.2 title. cdcr - 

<Action> Modified P-Spec 2.3.2 title to (Chute Release Control 
Processing) . ^ 

(*) P-Spec 2. 5.1; 3 "CRCP". 

(256) Control Flow "CHUTE_RELEASED" is defined as a data flow. 
<Action> Changed ' CHUTE_RELEASED' to a control flow in the DD . 

(*) P-Spec 2 . 5 . 2 ; 1 0 "CRCP". 

(257) I/O Entry: "CHUTE_RELEASED" is an input control flow. 

<Act ion> Changed ' CHUTE_RELEASE' to a data flow. 

(*) P-Spec 2. 5. 3; 2 "CRCP". 

(258) I/O Entry: " CHUTE_RELEASED " is an input control flow. 

<Action> Changed ' CHUTE_RELEASED' to a data flow. 

(*) DFD 2 . 6; 1 'GSP' . 

(259) DFD 2.6 bubble 2 (Gyroscope Sensor Processing) doesn't match 

P-Spec 2.6.2 title. (/,(’ . 

<Action> Modified P-Spec 2.6.2 title to (Gyroscope Sensor 
’Processing) . * 

(260) Data Flow "G_STATUS" is unmatched into DFD 2.6 bubble 2. 
<Action> Added 'G_STATUS' to the input list of P-Spec 2.6.2. 

(261) DDE "G_C0UNTER" has an invalid definition. 

<Action> Changed '*' to a ' -' in data type definition. 

(*) DFD 2. 7; 11 "GP" . 

(262) DFD 2.7 bubble 2 (Guidance Processing) doesn't match P-Spec 

2.7.2 title . _ 

<Action> Modified P-Spec 2.7.2 title to (Guidance Processing). 

(263) Data Flow "CL" not connected to a bubble or C-Spec connector. 
<Action> Redrew the flow so it connected both DFD 2.7 bubble 1 
and DFD 2.7 bubble 2, 

(264) Data Flow "CL" is unmatched into P-Spec 2.7.2. 

<Action> Added 'CL' to the input list of P-Spec ‘2.7.2. 

(265) Data Flow "CL" is unmatched out of P-Spec 2.7.2. 

<Action> Added 'CL' to the output list of P-Spec 2.7.2. 

(266) Data Flow "END_GCS" is unmatched out of DFD 2.7 bubble 2. 
<Action> Added 'END_GCS' to the output list of P-Spec 2.7.2. 

(267) Data Flow "MAX_NC>RMAL_VELOCITY " is unmatched in child 
P-Spec 2.7.2. 

<Action> Added ' MAX_NORMAL_VELOCITY' to the input list of. 
P-Spec 2.7.2. 
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Action Report Continuation 


page LJ of -i? 

| a. Report#: J 

I b. t'Jotes/Explanarion (Please reference appropriate section number): 


(268) Data Flow "MAX_NORMAL_VELOCITY" is unmatched out of DFD 2.1 
bubble 1 . 

<Action> Added ' MAX_NORMAL_VELOCITY' to the output list of 
P-Spec 2.7.1. 

(269) Data Flow "TE_INTEGRAL" not connected to a bubble or'C-Spec. 
<Action> Redrew the flow so it connected both DFD 2.7 bubble 1 
and DFD 2.7 bubble 2. 

(270) Data Flow "TE_INTEGRAL" is unmatched out of P-Spec 2.7.2. 
<Action> Added ' TE_INTEGRAL' to the output list of P-Spec 2.7.2. 

(*) DFD 2 .8/4 'RECLP' . 

(271) DFD 2.8 bubble 2 (Roll Engine Control Law Processing) doesn't 

match P-Spec 2.8.2 title. pfrciY — 

<Action> Modified P-Spec 2.8.2 title to j^Roll Engine Control 
Law Processing) . 

(272) Data Flow "DELTA_T" not connected to a bubble or C-Spec. 

<Act ion> Redrew the flow so it connected both DFD 2.8 bubble 1 
and DFD 2.8 bubble 2. 

(273) Data Flow "DELTA_T" is unmatched into P-Spec 2.8.2. 

<Action> Added 'DELTA_T' to the input list of P-Spec 2.8.2. 

(274) Data Flow "RE_STATUS" is unmatched into DFD 2.8 bubble 2. 
<Action> Added 'RE_STATUS' to the input list of P-Spec 2.8.2. 

(*) DFD 2. 9; 4 'TDLRSP'. 

(275) DFD 2.9 bubble 2 (Touch Down Landing Radar Sensor Processing) 
doesn't match P-Spec 2.9.2 title. 

<Action> Modified P-Spec 2.9.2 title to ^Touch Down Landing 
Radar Sensor Processing) . 

(276) Data Flow T D LR_S TAT US" is unmatched into DFD 2.9 bubble 2. 
<Action> Added ' TDLRj_STATUS' to the input list of P-Spec 2.9.;. 

(277) DDE "TDLR_COUNTER" has an invalid definition. 

<Action> Changed '*' to a '-' in data type definition. 
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GCS Problem Report 


2. Planet: 

PLUTO 


3. Discovery Date: 
Oct 15, 1993 


ace I of 2 


4. Initiator & Role: 

Inspectors/ Angcllntta mid Hcclicr 


.*5. Activity at Discovery: 



* Aclivit 

Development Phases DR 1 CR | RC | RS 1 IRR 
Design HjHHj 

Code pm 

Unit Testing 

Functional 

Structural 

Subframe Testing 

Frame Testing 

Top-Level 
Integration Testing 


fi. Description of Problem: 

There are several bubbles in the design which have no purpose. Because the 
P-Spccs for these bubbles do not specify any processing the bubbles arc 
extraneous to the design. The bubbles arc identified below. 

2. 1 . 1 AECLP - Axial Engine Expand Data Flows 

2. 1 .3 AECLP - Axial Engine Compress Data Flows 

2.2. 1 ARSP - Altimeter Radar Data Expand Data Flows 

2.2.3 ARSP - Altimeter Radar Data Compress Data Flows 

2.3.1 ASP - Acceleromter Expand Data Flows 

2.3.3 ASP - Acceleromter Compress Data Flows 

2.4. 1 CP - Communications Processing Expand Data Flows 

2.4.3 CP - Communications Processing Compress Data Flows 

2.4.4 CP - Communications Processing Expand GUIDANCE_STATE Data Stoic 

2.5.1 CRCP - Chute Release Expand Data Flows 
2.5.3 CRCP - Chute Release Compress Data Flows 


7. Artifact Identification: 

X Design Description 

Source Code 

Executable Object Code 


8. Test Case Identification: 


Support Documentation 
Other 


Configuration Item: 

Pluto Design Description 


9. History Log: 

Date To I Date From 


Person 


Comments 



It). Total ft of Changes: ^-3 


' 2 Inilifitnr ^innnltirn Sr* TYn/n 

| . Original Signed by 

Rob Angellatta 


1 1 . Total If of No Changes: O 


13. 5?(1A Sipiiftfiirp Jb flnlp 


FeloH, mu 


Original Signed by 
George Finelli 


7T/W 


* Aclivily: UR - Design Review; CR - Code Review; RC - Rending Code; RS - Rending Spccilicnlion; I UK - lest Rendincss Review; TCR - lest Completion Review; TCC 

* Test Case Creation; TCE - Test Case Execution; R - Repression; O - Other. 
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Problem Report Continuation 


page 2 of 2 


a. Report #: Pluto PR #2.0 


b. Notes/nxplanation (Please reference appropriate section number): 

2.6. 1 G.SP - Gyroscope Sensor Processing Expand Data Flows 

2.6.3 GSP - Gyroscope Sensor Processing Compress Data Flows 

2.7.1 GP - Guidance Processing Data Expand 

2.7.3 GP - Guidance Processing Data Compress 

2.8. 1 RECLP - Roll Engine Control Law Processing Data Expand 

2.8.3 RECLP - Roll Engine Control Law Processing Data Compress 

2.9.1 TDLRSP - Touch Down Landing Radar Sensor Processing Data Expand 

2.9.3 TDLRSP - Touch Down Landing Radar Sensor Processing Data Compress 

2.10.1 TDSP - Touch Down Expand Data Flows 

2. 10.3 TDSP - Touch Down Compress Data Flows 

2.11.1 TSP - Temperature Sensor Processing Data Expand 

2. 1 1 .3 TSP - Temperature Sensor Processing Data Compress 
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GCS Action Report 


page 1 of & 


1 1. AR#: 

2. Planet: 

3. Date of Action: 

4. Respondent & Role: 

2. P'1 

Pluto 

February 9,1994 

Car ter , P . Prog rammer 


5. Artifact Identification: 


2L Design Description Support Documentation Configuration Item: 

Source Code Other 

___ Executable Object Code 

Pluto Design Description 

6. Description of Action ~ . 

(***) DFD 2 ' RUN_GCS' . 

(*) DFD 2.1 "AECLP" . ' 

(1) DFD 2.1 "AECLP" is an unnecessary level of complexity in the 
model design. 

<Action> Deleted DFD 2.1 "AECLP" from the model. Retitled 
"AECLP" to "AECLP - Axial Engine Control Law Processing" in 
'RUN_GCS' . 

(2) P-Spec 2.1.1 "AECLP - Axial Engine Expand Data Flows". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.1.1 from the model. 

(3) P-Spec 2.1.3 "AECLP - Axial Engine Compress Data Flows". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.1.3 from the model. 

(4) P-Spec 2.1.2 "AECLP - Axial Engine Control Law Processing". 
<Action> Renamed this P-Spec to 2.1 making it the only P-Spec. 

(*) DFD 2.2 "ARSP" . 

(1) DFD 2.2 "ARSP" is an unnecessary level of complexity in the 
model design. 

<Act ion> Deleted DFD 2.2 "ARSP" from the model. Retitled "ARSP" 
to "ARSP - Altimeter Radar Sensor Processing" in 'RUN_GCS'. 

(2) P-Spec 2.2.1 "ARSP - Altimeter Radar Expand Data Flows". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.2.1 from the model. 

(3) P-Spec 2.2.3 "ARSP - Altimeter Radar Compress Data Flows". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.2.3 from the model. 

(4) P-Spec 2.2.2 "ARSP - Altimeter Radar Sensor Processing". 

<Act ion> Renamed this P-Spec to 2.2 making it the only P-Spec. 


7. Was the action related to another action(s)? Yes AR#(s) 

JL No 

I don't know 
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A ction Report Continuation 


page 2_ of _& 

a. Report ff: " " ™" 

2J£J 

b. Notes/Explanation (Please reference appropriate section number): 

(***) DFD 2 ' RUN_GCS ' . 

(*) DFD 2.3 "ASP". 

(1) DFD 2.3 "ASP" is an unnecessary level of complexity in the 
model design. 

<Action> Deleted DFD 2.3 "ASP" from the model. Retibled "ASP" 
to "ASP - Accelerometer Sensor Processing" in 'RUN GCS' . 

(2) P-Spec 2.3.1 "ASP - Accelerometer Expand Data Flows". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.3.1 from the model. 

(3) P-Spec 2.3.3 "ASP - Accelerometer Compress Data Flows". 

P-Spec is extraneous to the model design. 

<Act ion> Deleted P-Spec 2.3.3 from the model. 

(4) P-Spec 2.3.2 "ASP - Accelerometer Sensor Processing". 

<Action> Renamed this P-Spec to 2.3. making it the only P-Spec 

(*) DFD 2 . 4 "CP" . 

(1) DFD 2.4 "CP" is an unnecessary level of complexity in the 
model design. 

<Action> Deleted DFD 2.4 "CP" from the model. Retitled "CP" td 
"CP - Communications Processing" in 'RUN GCS'. 

P-Spec 2.4.1 "CP - Communications Processing Expand Data Flows' 
P-Spec is extraneous to the model design. 

<Act ion> Deleted P-Spec 2.4.1 from the model. 

(3) P-Spec 2.4.3 "CP - Communications Processing Compress Data Flows" 
P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.4.3 from the model. 

P-Spec 2.4.4 "CP - Communications Processing Expand 
GUIDANCE_STATE Data Store". 

P-Spec is extraneous to the model design. 

<Act ion> Deleted P-Spec 2.4.4 from the model. 

P-Spec 2.4.2 "CP - Communications Processing". 

<Action> Renamed this P-Spec to 2.4. making it the primary P-Spe 
Redrew DFD 2.4.5 bubble "CALCULATE CRC-16" off of bubble "CP" 
in ' RUN_GCS ' . Renamed bubble "CALCULATE CRC-16" to .19 and 
renamed the P-Spec for "CALCULATE CRC-16" to .19. 


( 2 ) 


(4) 

(5) 

( 6 ) 
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Action Report Continuation 


page 3 of fi 

a. Report #: 

2.01 

b. Notes/Explanation (Please reference appropriate section number): 


(***) DFD 2 ' RUN_GCS ' . 

(*) DFD 2.5 "CRCP" . 

(1) DFD 2.5 "CRCP" is an unnecessary level of complexity in the 

model design. ( 

<Action> Deleted DFD 2.5 "CRCP" from the model. Retitled "CRCP 
to "CRCP - Chute Release Control Processing" in 'RUN_GCS'. 

(2) P-Spec 2.5.1 "CRCP - Chute Release Expand Data Flows". 

P-Spec is extraneous to the model design. 

<Act ion> Deleted P-Spec 2.5.1 from the model. 

(3) P-Spec 2.5.3 "CRCP - Chute Release Compress Data Flows". 

P-Spec is extraneous to the model design. 

<Act ion> Deleted P-Spec 2.5.3 from the model. 

(4) P-Spec 2.5.2 "CRCP - Chute Release Control Processing". 

<Act ion> Renamed this P-Spec to 2.5. making it the only P-Spec. 
(*) DFD 2.6 "GSP" . 

(1) DFD 2.6 "GSP" is an unnecessary level of complexity in the 

model design. 

<Action> Deleted DFD 2.6 "GSP" from the model. Retitled "GSP" 
"GSP - Gyroscope Sensor Processing" in ' RUN_GCS'. 

(2) P-Spec 2.6.1 "GSP - Gyroscope Sensor Processing Expand Data 

Flows" . 

P-Spec is extraneous to the model design. 

<Act ion> Deleted P-Spec 2.6.1 from the model. 

(3) P-Spec 2.6.3 "GSP - Gyroscope Sensor Processing Compress Data 
Flows" . 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.6.3 from the model. 

(4) P-Spec 2.6.2 "GSP - Gyroscope Sensor Processing". 

<Act ion> Renamed this P-Spec to 2.6 making it the only P-Spec 



Action Report Continuation 


a. Report #: 

2^1 

b. Notes/Explanation (Please reference appropriate section number): 


page 




< 


* * * ) DFD 2 ' RUN_GCS ' . 

(*) DFD 2.7 "GP". 

(1) DFD 2.7 "GP" is an unnecessary level of complexity in the 
model design. 

<Action> Deleted DFD 2.7 "GP" from the model. Retitl'ed "GP" to 
"GP - Guidance Processing" in 'RUN_GCS'. 

(2) P-Spec 2.7.1 "GP - Guidance Processing Data Expand". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.7.1 from the model. 

(3) P-Spec 2.7.3 "GP - Guidance Processing Data Compress". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.7.3 from the model design. 

(4) P-Spec 2.7.2 "GP - Guidance Processing". 

<Action> Renamed this P-Spec to 2.7. making it the only P-Spec. 

(*) DFD 2.8 "RECLP " . 

(1) DFD 2.8 "RECLP" is an unnecessary level of complexity in the 
model design. 

<Action> Deleted DFD 2.8 "RECLP" from the model. Retitled "RECLP"| 
to "RECLP - Roll Engine Control Law Processing" in ' RUN GCS' 

(2) P-Spec 2.8.1 "RECLP - Roll Engine Control Law Processing Data 
Expand" . 

P-Spec is extraneous to the model design. 

<Act ion> Deleted P-Spec 2.8.1 from the model. 

(3) P-Spec 2.8.3 "RECLP - Roll Engine Control Law Processing Data 
Compress". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.8.3 from the model design. 

(4) P-Spec 2.8.2 "RECLP - Roll Engine Control Law Processing". 
<Action> Renamed this P-Spec to 2.8 . making it the only P-Spec. 
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Action Report Continuation 


page 5 l_ of -& 

a. Report it: 

2.Qf\ 

b. Notes/Explanation (Please reference appropriate section number): 

(***) DFD 2 ' RUN_GCS' . 

(*) DFD 2.9 "TDLRSP" . 

(1) DFD 2.9 "TDLRSP" is an unnecessary level of complexity in the 
model design. 

<Action> Deleted DFD 2.9 "TDLRSP" from the model. Retitled 
"TDLRSP" to "TDLRSP - Touch Down Landing Radar Sensor Processing" 
in ' RUN_GCS ' . 

(2) P-Spec 2.9.1 "TDLRSP - Touch Down Landing Radar Sensor Processing 
Data Expand" . 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.9.1 from the model. 

(3) P-Spec 2.9.3 "TDLRSP - Touch Down Landing Radar Data Comp". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.9.3 from the model. 

(4) P-Spec 2.9.2 "TDLRSP - Touch Down Landing Radar Sensor 
Processing". 

<Action> Renamed this P-Spec to 2.9, making it the only P-Spec. 

(*) DFD 2.10 "TDSP" . 

(1) DFD 2.10 "TDSP" is an unnecessary level of complexity 
in the model design. 

<Act ion> Deleted DFD 2.10 "TDSP" from the model. Retitled "TDSP’ 
to "TDSP - Touch Down Sensor Processing" in 'RUN_GCS'. 

(2) P-Spec 2.10.1 "TDSP - Touch Down Expand Data Flows". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.10.1 from the model. 

(3) P-Spec 2.10.3 "TDSP - Touch Down Compress Data Flows". 

P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.10.3 from the model. 

(4) P-Spec 2.10.2 "TDSP - Touch Down Sensor Processing". 

<Action> Renamed this P-Spec to 2.10- making it the only P-Spec. 
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Action Report Continuation 


page§_of .£. 


a. Report #: 

2 . 1/1 

b. Notes/Explanation (Please reference appropriate section number): 

(***) DFD 2 ' RUN_GCS' . 

(*) DFD 2.11 "TSP". 

(1) DFD 2.11 "TSP" is an unnecessary level of complexity in the 
model design. 

<Act ion> Deleted DFD 2.11 "TSP" from the model. Reti'tled "TSP" 
to "TSP - Temperature Sensor Processing" in 'RUN_GCS' . 

(2) P-Spec 2.11.1 "TSP - Temperature Sensor Processing Data Expand". 
P-Spec is extraneous to the model design.. 

<Action> Deleted P-Spec 2.11.1 from the model. 

(3) P-Spec 2.11.3 "TSP - Temperature Sensor Processing Data Compress" 
P-Spec is extraneous to the model design. 

<Action> Deleted P-Spec 2.11.3 from the model. 

(4) P-Spec 2.11.2 "TSP - Temperature Sensor Processing". 

<Action> Renamed this P-Spec to 2.11. making it the only P-Spec. 


E-46 




GCS Problem Report 


2. Planet: 

PLUTO 


3. Discover)' Date: 
Oct 15, 1993 


page I of 2 


4. Initiator & Role: 

Inspectors/ Quacli anil Bcclicr 


5. Activity at Discovery: 


* Activity 

CR I RC I RS I TRR 1 TCR I TCC I TCE 


Development Phases I DR RS I R Q 

Design ^ 

Code pM I I 

Unit Testing 

Functional i 

Structural 

Subframe Testing 

Frame Testing 

Top-Level Simulator 

Integration Testing 

6. Description of Problem: 

The following problems were identified in the TSP functional unit: 

1) The data element TS_STATUS, contained in the data flow named TEMP GS JN, is depicted as an input 
to the process 2. 1 1 TSP. This is inconsistent with the TSP process as defined in the GCS Software 
Requirements. 

2) The algorithm for determining the atmospheric temperature as computed from the data provided by the 
solid-state temperature sensor is lacking an adequate description. The design does not provide enough 
information to derive the equations. 

3) The algorithm for determining the atmospheric temperature as computed from the data provided by the 
thermocouple-pair temperature sensor is lacking an adequate description. The design does not provide 
enough information to derive the equations if necessary for a future modification. 


7. Artifact Identification: 

X Design Description 

__ Source Code 

__ Executable Object Code 


8. Test Case Identification: 


9. History' Log: 

Date To I Dale From I Person 


Support Documentation 
Other 


Configuration Item: 

Pluto Design Description 

P-Spcc 2.11 TSP - Temperature Sensor 

Processing 


Comments 



I 10. Total fl of Chances: n 11. Total# of No Changes: 

12. Initiator Signature A Dote 13. SOA Signature <$. Date „ . t i 

|_ Original Signed by 6-/7~ ‘ft _Original Signed by m i 

Patrick Quach Kelly Hayhurst 

♦ Activity: DR - Design Review; CR - Code Review; RC - Reading Code; RS - Reading Specification: TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Ctgajipn; TCE - Test Case Execution; R - Regression; O - Other. 





Problem Report Continuation 


page 2 of 2 


a. Report H: 3.0 


b. Notes/Explanation (Please reference appropriate section number): 

4) In reference to the following code segment (page 4): 

•k'k'k'k-k’k-kJc'kic'k'k'k-k'k'k'k'k'k'k'k'k'k'k'k’k'k-k'k'k'k'k'k'k'k'k-k'k'k'k'k-k'k'kic'k'k-k-ki' 

* Determine which expression to use to calculate * , 

* THERMOCOUPLE temperature: * 

"if (THERMO TEMP >= lo meas limit tc 

and 

THERMO TEMP < M3 . . . " 

"ELSE IF (THERMO TEMP > m4 

AND 

THERMO TEMP <= hi meas limit tc) " 

Problem: In the first conditional, the first relational expression is unnecessary, and in the second conditional 
the second relational expression is unnecessary. 

5) All of the local variables of type REAL are declared as single precision — real*4. It is possible to lose 
precision in the computation of the atmospheric temperature. 






GCS Action Report 


page I of i 


1. A lift- 

2. Planet: 

3. Date ol Action: 

4. Respondent & Role: 

3.1 

Pluto 

April 19, 1994 

Angellatta, R.K. Programmer 

5. Artifact Identification: 


Configuration Item: 

X Design Description 
Source Code 
Executable Object Code 

Support Documentation 
Other 

Pluto Design Description 
P-Spec 2.11 TSP 


6. Description of Action 


1) The data element TS_STATUS was removed from the list of inputs for 

P-Spec 2.11. t 

The data flow labeled TEMP_GS_IN was removed from DFD 2. 

The data dictionary entry TEMP_GS_IN was removed from the data dic- 
tionary as it simply renamed the data element TS STATUS. 

2) P-Spec 2.11 has been modified to include a complete description of 
the algorithm for computing the atmospheric temperature from the meas- 
urement provided by the solid-state sensor. 

3) P-Spec 2.11 has been modified to include a complete description of 
the algorithm for computing the atmospheric temperature from the meas- 
urement provided by the Thermocouple-pair sensor. 

4) The "code segment" in question has been redesigned to avoid unneces- 
sary relational evaluations. 

5) Since this is really a design and not code, all references to vari- 
able types have been removed from P-Spec 2.11. 

EXTRA: 

XI) It seems extraneous to create a data flow to contain a single data 
element. In DFD 2, the data flow labeled TEMP_GS_OUT was relabeled to 

TS STATUS and the data dictionary element TEMP_GS_OUT has been removed 

from the data dictionary. 

X2) In DFD 2, the data flow labeled TEMP_SO_OUT was relabeled to ATMOS- 
PHERIC_TEMP and the data dictionary element TEMP_SO_OUT has been re- 
moved from the data dictionary. 

NOTES: 

The entire P-Spec 2.11 TSP has been redesigned. 


7. Was the action related to another action(s)7 Yes AR#(s) 

X No 

Do not know 
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GCS Problem Report 


2. Planet: 


Pluto 


3. Discovery Date: 
Oct. 15, 1993 


page 1 of 2_ 


4. Initiator & Role: 

Inspcclor/Quacli and Bcclicr 


5. Activity at Discovery: 


* Activity 

Development Phases H DR I CR I RC I RS I IRR I I CR 1 I CC | ICE | 



6. Description of Problem: 


The following are Inconsistencies and deficiencies for the ARSP PSpcc. 2.2 in the Pluto Design 
Description that need to be addressed. 

1) in reference to the following pseudo-code on page 2 

if (FRAME_COUNTER -= even) 

AR_ALTITUDE . * - AR_ALTITUDE . (previous value] 

AR_STATUS . * ~ AR_STATUS . [previous value] 

K_ALT . * = K_ALT . [previous value]" 

a) The syntax (used throughout the PSpec) Is Inconsistent with Its definition. 

b) The expression "Iprcvlous valucl” does not clearly stipulate which previous value of the FIFO to 
use. 

c) The description for the FIFO opcratlonn directly before this code Is very vague. Adding this code 
Implies an extra FIFO shift on even FRAME_COUNTER. 


7. Artifact Identification: 

X Design Description Support Documentation Configuration Item: 

Source Code _ Other Pluto Design Description 

Executable Object Code 


8. Test Case Identification: 


9. Hislo r y Lop 
Date To 


Person 

Comments 

ARtf 

WBMBEBU 


Angellatta 


mmm ■ 

E9Z3NEB 

Bfjmni 

Quach 




mrmm 

Hayhurst 





c r 




10. Total ft of Changes: ft 1 1 . Total II of No Changes: 


12. Initiator Signatured Date 

13. SOA Signature & Ualc 

Original Signed by 4 - 2 f ~ ^ 0- 

Original Signed by S /&]<?*/ 


Patrick Quach Kelly Hayhurst 

* Activity: DR - Design Review; CR - Code Review; RC - Reading Code; KS - Reading specification; I RR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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Problem Report Continuation 


page 2 of 2 

a. Report tf: 

4>0 

b. Notcs/Explanation (Please reference appropriate section number): 

2) To estimate the altitude when sensor data (namely AR_COUNTER) Is not available, the Newton Divide 
Difference Is used. It (the Newton Method) Is describe as a series operations to build a table from 
which the next value Is estimated. 

a) The ordering of the entries In the table (which can allcct the final result) Is not specified. 

b) The operand ordering In operations to build successive columns (a Tier column 1) Is also not 

specified. < 

c) Insufficient explanation for Newton Method. 

3) With reference to the following on page 3 or ARSP PSpec, 

if (AR_FREQUENCY == 0)... 

a) AR_FREQUENCY Is unnecessarily tested for zero. 

b) Non-FORI'RAN 77 notation Is used In the "If clause. 

4) A lower limit check Is performed afler AR_ALTITUDE Is calculated, but an upper limit check Is not 
performed. Further, when an extrapolating AR_ALTITUDE, neither limits are lesled. 

5) In the pseudo code to calculate AR_AI,TITUDE on page 3: 

AR_AI<TXTUDE . [0] = (AR_COUNTER * 3 * 10**0 ) / AR_FRF.OUF.UCY * 2 

The order of operation of the last divide and multiply Is left open lor Interpretation. 

6) With reference to the limits checking on page 2 Tor the following Input variables: 

AR_STATUS 

K_ALT 

AR ALTITUDE 


Limits are checked only when the FRAME_COUNTER Is even. This docs not cover odd 
FRAME_COUNTERS 
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GCS Action Report 


page I of i 


1. ARtf: 

2. Planet: 

3. Date of Action: 

4. Respondent & Role: 

4 . 1 

Fluto 

April 29, 1994 

Angellatta, R.K. Programmer 

5. Artifact Identification: 


Configuration Item: 

X Design Description 
Source Code 
Executable Object Code 

Support Documentation 
Other 

Pluto Design Description 
P-Spec 2.2 ARSP 


6. Description of Action 
1 ) 


r\* r"-f 

A | 
tof-l 




a) All data elements previously reference using the ambiguous syntax 
"•*" have been modified as necessary to reference specific array ele- 
ments. The ".*" syntax has been highlighted in the enclosed "old" 
version of P-Spec 2.2. The changes are too numerous to explicitly 
document in the "new" version of P-Spec 2.2 
b) and c) The statements in question are not necessary and have been 
removed from the design (note lc) . Additionally, the "rotate vari- 
ables" algorithm has been replaced and now explicitly describes the 
concept of "shifting" (note lx) . 

2) a) , b) , and c) The design has been modified to include a complete 
description of how the divided difference method is applied in deriv- 
ing the equation for extrapolating the altitude (note 2) . The previ- 
ous description has been removed from the design. 

3) The cited statement is not necessary and has been removed from the 
design . 

4) In accordance with GCS Development Specification v 2.3, range check- 
ing is no longer necessary for AR_ALT I TUDE in this module. So, the 
range checking that was present has been removed. 

5) The cited statement has been modified to describe the proper equation 
(note 5) . 

6) In accordance with GCS Development Specification v 2.3, range check- 
ing is no longer necessary for AR_ALTITUDE, AR_STATUS , or K_ALT in 
this module. So, the range checking that was present has been removed. 


7. Was the action related to another action(s)? 


Yes AR#(s) 
X No 

Do not know 
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GCS Problem Report 


l.PR#: 

5 

2. Planet: 

Pluto 

3. Discovery Date: 
Oct. 15, 1993 

4. Initiator & Role: 

Inspcctor/Quach and Bcclicr 

5. Activity at Discovery: 

Development Phases II DR 

* Aclivi 

1 CR 1 RC 1 RS 1 TRR 

T TCR 1 TCC 1 TCE 1 R 1 O I 


Design 


Code 


Unit Testing 


Functional 


Structural 


Subframe Testing 


Frame Testing 


Top-Level Simulator 
Integration Testing 



6. Description of Problem: 

The following are Inconsistencies and deficiencies for the ASP unit (PSpcc. 2.3) In the Pluto Design 
Description that need to be addressed. 

1) In reference Local variables declared at the beginning or the ASP PSpcc: 

BEGIN LOCAL TYPE DEFS 
real a_gain.* 


real hold 

END LOCAL TYPE DEFS’ 


Variable size Is ambiguous. 


2) Description for rotating history variables Is vague. The notation is not used according to Its 
definition In the Design Description Preface 


7. Artifact Identification: 

X Design Description 
_ Source Code 

Executable Object Code 


Support Documentation 
Ollier 


Configuration Item: 

Pluto Design Description 


8. Test Case Identification: 


9. History Log 
Date To 



Person 


Comments 


j Angellatta 
Quach 
.Hayhurst 
6 


I 


ARfl 


Jul- 


10. Total ft of Changes: j£_ 


1 1 . Total ff of No Changes: 

13. SOA Signature & Dale 


12. Initiator Signature & Date 

^Original Signed by 
Patrick Quach 




Original Signed by 
"Kelly Hayhurst 


ikkl 


* Activity UK - ucsign Kcvicw; CR - Code Review; RC - Reading Code; to - Kcaumg apcc... canon; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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Problem Report Continuation 


page _2_ of _2_ 


a. Report tt\ 
5 


b. Notes/Pxplanation (Please reference appropriate section number): 

3) In reference to the following: 

at = ATMOS PHERIC_TEMP 

Shortening the variable name makes the subsequent equation less obvious. 

4) Notation used for the pseudo-code which calculates the standard deviation is very confusing and can 
be misinterpreted. 

5) In reference to the notation describing axis alllgnmcnt: 

accel.* = ALPHA_MATRIX . * . * * accel. * 

The required matrix multiplication is not apparent from the notation. 


6) In reference to status check of previous STATUS values: 
if [A_STATUS . * . [all 1..3J... 

It is not clear which variable is being tested. 




GCS Action Report 


pace I ol x 



2. Planet: 


4. Respondent & Role: 

1 

Pluto 


Angellatta, R.K. Programmer 

5. Artifact Identification: 


Configuration Item: 

X Design Description 
SotitcT Code 
Executable Object Code 

Support Documentation 
Other 

Fluto Design Description 
P-Spec 2 . 3 ASP 


6. Description of Action 


1) Since this is really a design and not code, all references to vari- 
able types have been removed from P-Spec 2.3. Local data elements are 
referenced where necessary; their types must be determined during the 
implementation process. 

2) All data elements previously reference using the ambiguous syntax 

have been modified as necessary to reference specific array ele- 
ments. The "rotate variables" algorithm has been replaced and now 
explicitly describes the concept of "shifting." 

3) The design has been modified such that the data element ATMOS- 

PHERIC TEMP is not renamed to "at." 

4) The algorithm for specifying the standard deviation operation has 

been modified in anti effort to reduce ambiguity. 

KJ)* ‘/>|» / 

5) A statement has been added to the design explicitly noting the matrix 
multiplication . 

6) The cited statement has been modified to explicitly reference the 
array entries of the data element A_STATUS . 


7. Was the action related to another action(s)? Yes AR#(s) 

X No 

Do not know 
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GCS Problem Report 


1. PR #: 


2. Planet: 


3. Discovery Date: 
Oct. 15, 1993 


ace 1 of 1 


4. Initiator & Role: 

Inspcclor/Quacli and Beefier 


5. Activity at Discovery: 


* Activity 

Development Phases II DR ^ — 

Design ^ 

Code IH IHR mam 

Unit Testing ^ 

Functional ^ 

Structural ^ i 

Subframe Testing ^ 

Frame Testing ^ 

Top-Level ^ 

Integration Testing 

6. Description of Problem: 

The following are Inconsistencies and deficiencies Tor the GSP unit (PSpec. 2.6) In the Pluto Design 
Description that need to be addressed. 

1) The variable G STATUS Is Incorrectly listed as an Input. 

' — ' « 

2) The description Is ambiguous for shifting the history variable G_ROTATION, . 

3) Loss of precision occurs due to assignment of ATMOSPHERICJTEMP and G_GAIN to local buffers 
declared as "REALM". 

. 4) With reference to the "1AND" function used In the 2's complement conversion: "IAND" Is a VAX 
FORTRAN extension atid not standard FORTRAN 77 notation. 


7. Artifact Identification: 

X Design Description 

_ Source Code 

Executable Object Code 

8. Test Case Identification: 


Support Documentation 
Ollier 


Configuration Item: 

Pluto Design Description 


9. History Log: 
Date To 1 


Dale From 


Person 
_ Angellatta 
;Quach 
Hayhurst 


Comments 


10. Total fl of Changes: JL 1 1 . Total ft of No Changes: 

12. Initiator Signature & Date | 13. SO A Sicnalurc & Date- 

Original Signed by Original Signed by 

~ Patrick Quach Kelly Hayhurst 

* Activity uk - ucsign kcvicw; CR - Code Review; RC - Reading Code; KS - Heading Speculation; 1 RR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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2. Planet: 
Pluto 


5. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


GCS Action Report 

page I of 2 


4. Respondent & Role: 

Angellatta, R.K. Programmer 


Configuration Item: 

Support Documentation pluto Des ign Description 

01 ,Gr P-Spec 2.6 GSP 



6. Description of Action 

1) The data element G_STATUS was removed from the list of inputs for 
©*P-Spec 2.6. The data flow labeled GYRO_GS_IN was removed from DFD 
2 . The data dictionary entry GYRO_GS_IN was removed from the data 
dictionary as it simply renamed the data element G_STATUS . 

2) The "rotate variables" algorithm has been replaced and now explicitly 
describes the concept of "shifting" the history data element 

G_RO TAT I ON . 

3) Since this is really a design and not code, all references to vari- 
able types have been removed from P-Spec 2.6. 

* 

4) The syntax used to describe the design has been altered and no longer 
follows FORTRAN-77 syntax. The portion of the design which calls for 
a two' s complement conversion has been restated with additional com- 
ments included in the description. 

EXTRA: 

Several of the data flows entering/exiting P-Spec 2.6 GSP contain a 
single data element. This serves to simply rename a data flow. These 
data flows have been removed from the data dictionary and the flows, 
which appear in DFD 2 RUN_GCS, have been renamed to the single data 
element they originally represented. 

IX) The data flow named GYRO_EXT_IN contained the single data element 
G COUNTER. This flow has been deleted from the data dictionary and 
DFD 2 RUN_GCS has been modified replacing GYRO_EXT_IN with G_COUNTER 
as input to P-Spec 2.6 GSP. The data dictionary entry named EXTERNAL 
has also been modified replacing the entry GYRO_EXT IN with G_COUNTER. 

2X) The data flow named GYRO_SO_OUT contained the single data element 
G ROTATION. This flow has been deleted from the data dictionary and 
DFD 2 RUN GCS has been modified replacing GYRO SO OUT with G ROTATION. 

3X) The data flow named GYRO_GS_OUT contained the single data element 

G STATUS. This flow has been deleted from the data dictionary and DFD 
2 RUN GCS has been modified replacing GYRO_GS_OUT with G_STATUS. 


7. Was the action related to another action(s)? 


Yes AR#(s) 
X No 

Do not blow 
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Action Report Continuation 


page 2 of 2 



b. Notes/Explanation (Please reference appropriate section number): 

4X) In accordance with GCS Development Specification v 2.3, range 
checking is no longer necessary for G_ROTATION in this module. So, 
the range checking that was present has been removed. 
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GCS Problem Report 


page I of 2 


2. Planet: 

3. Discovery Date: 

4. Initiator & Roic: 

Pluto 

Oct. 15, 1993 

lnspcctor/Quach and Bcchcr 


5. Activity at Discovery: 


* Activit 


Development Phases 

1 DR 1 CR 1 

RC 1 RS 

TRR 1 TCR 1 ICC 1 TCE I 

R 

O 

Design 

LxJHH 




Code 

HHh 





Unit Testing 










Functional 

■ 









Structural 







« 


Subframe Testing 









Frame Testing 









Top-Level Simulator 
Integration Testing 






■ 




6. Description of Problem: 

The following are Inconsistencies and deficiencies for the TDLRSP PSpcc. 2.9 in the Pluto Design 
Description that need to be addressed. 

1) Use of the and the notation in the local type definition is unclear and not consistent with 
their previous definition. 

2) FIFO data shirt description is ambiguous. Direction of rotation is not specified in "Rotate variable" 

3) The limit checking for TDLR_VELOCITY on page 2 of the PSpcc uses a ".x" notation. This Is not 
previously explained. 

4) The limit checking for K_MATRIX is unclear and unnecessary. 


7. Artifact Identification: 

X Design Description Support Documentation Configuration Item: 

_ Source Code _ Other Pluto Design Description 

Executable Object Code 


8. Test Case Identification: 



■Hi 

mBERfllH 

Comments 

AR# 

wrnn&m 


IK 



U 





■ 



wemm 


WRIflEE 

LI 






■ 


MigSJSf 

10. Total # of Changes: Q 

li. 

Total # of No Changes: 



12. Initiator-Sicnature & Date 

priginal Signed by 

Patrick Quach 




13. SOA Sicnaturc & Date 

Original Signed by 
Kelly Hayhurst 



* Activity: DK - Design Review; CR - Code Review; RC - Reading Couc; ks - Kenning specification; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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Problem Report Continuation 


page _2_ of __2_ 

a. Report ft: 

7 

b. Notes/Explanation (Please reference appropriate section number): 

5) In reference to the description for even FRAME_COUNTER processing: 

if (PRAME_COUNTER == even) 

set TDLR_VELOCITY.* to previous value ofTDLR_VELOCITY.* 

set K_MATR!X.* t(* previous value of K_MATRIX.* , 

exit. 

a) Tiie statement "Set ... to previous value of ..." arc ambiguous. 

b) Typo. "TDLR_VELOCnYV.*" 

6) Unnccessaiy limit checking for: 

a) TDLR_STATE 

b) FRAME_BEAM UNLOCKED 

c) TDLR_VELOCITY 

7) The IF cluster of statement which test wlictlicr a beam is locked and can be used: 

a) 'I lie logic for the Locked and unlocked case is not mutually exclusive.. 

b) FRAME_BEAM_UNLOCKED is incorrectly set. 

8) A description for calculating vehicle average velocities (page 4) for classes 2 to 4 is missing. 

9) The description to calculate the average velocity: 


bcam_vel.# = TDLR_OF FSET + (TDLR_GAIN * TDLR_COUNTER.ff) 

Ambiguous description of the processing sequence to calculate Individual beam velocities and 
average beam velocity. 
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GCS Action Report 




page 1 ol i 

1. AR#: 

7.1 

2. Planet: 
Pluto 

Dale ol Action: 
May 6, 1994 

4. Respondent & Role: 

Angellatta, R.K. Procji ammer 

Anifacl Identification: 

X Design Description 
Source C ode 
Executable Object Code 

Support I locumentation 
Other 

Configuration Item: 

Fluto Design Description 
P-Spec 2.9 TDLRSP 

h. Description of Action 


1> A1 i elements Previously reference using the ambiguous syntax 

and ".#" have been modified as necessary to reference specific array 
elements. « J 

2) The "rotate variables" algorithm has been replaced and now explicitly 
describes the concept of "shifting" the history data elements 
TDLR_VELOCITY and K_MATRIX. 

3) In accordance with GCS Development Specification v 2.3, range checking 
is no longer necessary for TDLR_VELOCITY in this modulo. So, the range 
checking that was present has been removed. 

4) The range checking for K_MATRIX has been removed. 

5) a) and b) The cited statements have been removed from the design as 
they are not necessary. 

6) The range checking for TDLR_S TATE , FRAME BEAM UNLOCKED, and 
TDLR_VELOCITY has been removed from the design. 

7) a) and b) The description for determining the "beam state" has been 
modified to improve clarity and correct the cited defiencies. 

8) A complete description for computing the vehicle average velocities 
also referred to as the "processed" beam velocities, for all classes 
has been added to the design. 

9) The description for computing the beam velocities has been modified to 
remove the ambiguous syntax ".#". 


7. Was (lie action related to another action(s)? 


Yes ARtt(s) 
X No 

Do not know 
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GCS Problem Report 


I. PR «: 


8 


2. Planet: 

3. Discovery Date: 

Pluto 

Oct. 15, 1993 


4. Initiator & Role: 

Inspcclor/Quach and Bcchcr 


page 1 of 1 


5. Activity at Discovery: 

Development Phases 


Design 


Code 


Unit Testing 


Functional 


Structural 


Subframe Testing 


Frame Testing 



Top-Level Simulator 
Integration Testing 

6. Description of Problem: 

Hie following are Inconsistencies and deficiencies for the TDSP PSpcc. 2. 10 In the Pluto Design 
Description that need to be addressed. me nuio uesign 

1) I he term "unhealthy" used In the PSpcc Is not consistent with what Is used In the Specification. 

2) The assignment: 

all_oncs = -1 

TD - COUmE * ""V «■ nw "O' be .rue of ,„e p.n.ronu 

3) The last branch In the TD_STATUS If statement: 

else 

Give message ”TDS_STATUS lias bad value..." 

This branch Is unnecessary 

4) Limits testing for the following are unnecessary 
TD SENSED 

TPS STATUS 


7. Artifact Identification: 

X Design Description 

Source Code 

_ Executable Object Code 


Support Documentation 
Ollier 


Configuration Item: 

Pluto Design Description 


8. Test Case Identification: 


HsSSjSI 

WSM 

Person 

Comments 

— 


HI 



■m 

SSJSmS 

wtEwtnt 





wOBSEEW 




10. Total ft of 

— ' 

Changes: <-l 

wm 

Tralnl « r»r Ktn rlmnni... 



Original Signed by 
Patrick Quach 




13. SOA Signature & Date 

Original Signed by 
Kelly Hayhurst 






^ xiujniuioi 

Review'-' T cTtc^ • C ^ r R T w >? C • Rca, ! in 8 b* • Kcaamg apeemcarion; TRR . Test Readiness 
Review, ICR ■ Test Complclion Review; TCC • Test Case Creation; TCE ■ Test Case Execution; R . Regression; 0 - Ollier. 
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2. Planet: 
Pluto 


5. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


6. Description of Action 


GCS Action Report 

page I of 1 


4. Kesponilem <*c Role: 

Angellatta, R.K. Programmer 


E 



Support Documentation 
Other 


Configuration Item: 

Pluto Design Description 
P-Spec 2.10 TDSP 


1) The term "unhealthy" has been removed from P— Spec 2.10. References to 
the term have been replace with the value "1" and commented with the 
appropriate term "failed." 

2) The syntax for referencing "all_ones" has been modified to use hexa- 
decimal notation. 

3) The cited statement is unnecessary and has been removed from the de- 
sign . 

4) The cited range checking is unnecessary and has been removed from the 
design. 


7. Was the action related to another action(s)? 


Yes ARr/(s) 
X No 

Do not know 
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GCS Problem Report 


page 1 of 2. 


• 1. PR «: ” 

2. Planet: 

3. Discovery Date: 

4. Initiator & Role: 

9 

1 

Pluto 

Oct. 15, 1993 

Inspcclor/Quach and Bcchcr 


5. Activity at Discovery: 

* Activit 


Development Phases 

1 DR 1 CR 1 

RC 1 RS 

iTRRj 

ICR 1 TCC 1 ICE 1 

R 

O 

Design 

L_x^ 

I 



Code 






Unit Testing 

■ 









Functional 









Structural 







l 


Subframe Testing 









Frame Testing 









Top-Level Simulator 
Integration Testing 






| 




6. Description of Problem: 

The following are Inconsistencies and deficiencies for the RECLP PSpec. 2.8 In the Pluto Design 
Description that need to be addressed. 

Sy- 

1) Unnecessary range checking Or RE_SWITCH on top of page 2. 

2) When performing range checking for G_ROTATION, the notation 

G_ROTATION.x ... 

Is ambiguous. Since G_ROTATION Is a 3 by 5 matrix. It Is not clear which element Is being tested. 

3) Concerning the limit checking for the variable THETA: 

a) The variable PI Is assumed to have the mathematical value. Its value as used In the context of 
this bounds checking Is not clearly defined 

b) The limit checking forces THETA to be exactly PI. This Is Incorrect. 

d) References to the figure which describes roll engine command settings should be updated. 

5) The description for determining the region of Interest on the roll engine command graph with which 
to derive the roll engine command lacks sufficient detail to derive an algorithm. 


7. Artifact Identification: 

X Design Description 

Source Code 

Executable Object Code 

Support Documentation Configuration Item: 

Oilier Pluto Design Description 


8. Test Case Identification: 


: 







Person 


Comments 

AR# 

wsmnm 


Angellatta 

— 

_u 

wsmmm 

mmzam 

Quach 



WHIM m 

winmm i 

Hayhurst 





* V 



1 0. Total ft of Changes: T _ 

11. 

Total ff of No Changes: 


12. Initiator Signature. A Date 

- 


13. SOA Signature & Dale 


^Original Signed by 


v5 -14- 

(Original Signed by 5 / / yiy 


ran l^ts. yuatn 

Activity: DR - Design Review; CR - Code Review; RC - Reading Code; RS - Reading Specification; TRR - Test P 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - 


Readiness 

Other. 
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Problem Report Continuation 


page 2 of 2 


a. Report tt: 

2 

b. Notcs/Explanalion (Please reference appropriate section number): 

6) The description for building the roll engine command uses the terms 

lowest bit 
second lowest bit 
third lowest bit 

but docs not specifically define the notation used. 

7) Concerning the programming Instructions for the last "else" branch 

which contains the comment "you should not be able to reach this region..." 

a) It Is not clear which part of the Specification this logic traces to. 

b) The Instruction to print error message Is Inadequate. 
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GCS Action Report 


pace 1 of i 



2. Planet: 


4. Respondent & Role: 


Fluto 


Angellatta, R.K. Programmer 

5. Artifact Identification: 


Configuration Item 

X Design Description 
Source Code 
Executable Object Code 

Support Documentation 
Other 

Pluto Design Description 
P-Spec 2.8 RECLP 


6. Description of Action 


1) Range checking of the data element RE_SWITCH has been removed from 

P-Spec 2.8. i 

2) The range checking for the x-axis vehicle rotation rate has been modi- 
fied to specify data element G_ROTATION (1 , 0) . 

3) a) P-Spec 2.8 has been modified giving a specific value for "PI." 
b) The range checking of the data element THETA has been corrected. 

4) The cited reference has been updated to reflect the version 2.3 of the 
GCS development specification. 

« 

5) A complete description of the algorithm for determining the roll en- 
gine command has been provided in P-Spec 2.8. 

6) The description for determining the roll engine command has been modi- 
fied (item 5) and the cited terms have been removed from P-Spec 2.8 

7) The cited "else" statement is unnecessary and has been removed from 
P-Spec 2.8. 


7. Was the action related to another action(s)? Yes AR#(s) 

X No 

Do not know 
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GCS Problem Report 


pane I of 2_ 


2. Planet: 

3. Discovery Date: 

4. initiator & Role: 

Pluto 

Oct. 15. 1993 

Inspcctor/Quacb and Bcclicr 


5. Activity at Discovery: 

Development Phases 


* Activity 

I DR I CR I RC I RS I I RR 1 TCR I ICC I TCP I R 



Frame Testing 
Top-Level Simulator 
Integration Testing 


fi. Description of Problem: 

The following arc Inconsistencies and deficiencies for the AECLP P-Spce.. 2. 1 In the Pluto Design 
Description that need to be addressed. 


[jfrpAE 


1) Unnecessary range checking iff' AE_SWITCI I on page 3. 

2) An algorithm for the AE_TEMP Is missing. 

3) In calculating thcla(local variable) for the PEJNTEGRAL and the YEJNTEGRAL: 

a) GP_VELOCTTY Is a 2 dimensional matrix but only 1 dimension Is 
referenced In the divide by zero check as well as the theta calculation. 

b) The Spec. Indicates that the absolute value of the GIM7ELOCITY 
component Is to be used In the divide. 

c) The name of local variable "theta" may conflict with the global variable 
name "THETA" In some Implementation languages. 

4) Unnecessary boundary check for: 

AE.TEMP 

CONTOUR CROSSED 


7. Artifact Identification: 

X Design Description 

Source Code 

Executable Object Code 


Support Documentation 
Ollier 


Configuration Item: 

Pluto Design Description 

T-'Spec S>.\ 

^*9 


8. Test Case Identification: 




Person 

Comments 

AR# 

Eirnfsi 


Angellatta r 


fo. 1 


WdyjHiMN 

1 



WBEItSM 

wnmnm 




' 

1 ' 




1 0. Total tt of Changes: JLST 

ii. 

Total tt of No Changes: 

\ 




13. SOA Signature & Date 
.Original Signed by 


'dlkd. 


12. Initiator Signature icDate 

.Original Signed by 

“Patrick Quach Kelly Hayhurst 

* Activity: ijk - ucsign Review; CR - Code Review; RC - Reading Code; KS - Reading .'spccilication; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 

/ 
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Problem Report Continuation 


■ page 2 of 2 

a. Report ff: 

10 

b. Notes/Expl.'ination (Please reference appropriate section number): 

5) I he calculation for limlling_pllch_error and limitin£_yaw_crror arc done In 2 steps unnecessarily. 

G) With reference to the bounds checking for the following: 

n) A_ACCELERATION uses 2 different indexing notations to reference the element being tested: it is 
not clear which element Is being tested 

b) The 1 dimension array. GP_ALTITUDE. is referenced as a 3 dimensional array. 

c) Bounds checking is missing for the following: 

GPJYITITUDE. 

GP_VELOCITY 

d) Nesting the bounds checking inside the if statements makes the if blocks very dimcult to follow. 
It Is not clear whether the bounds checking Is actually performed. 

7) The design Includes assignments of TEJJMIT based on AEJEMP. This Is not in the Spec. 

8) The design has not shown the derivation of the equation used to solve the differential equation for 
TEJJMIT. 

9) In reference to the following description for calculation TEJJMIT: 

(|Jcmp = -GAX(... * GP_ALTITUDH( I, .1.0)... VELOCITY J-RROR + GVEl(CL + THJNTEGRAL 
(|_ovcr_omcgi) = ( GA * ((|_tcmp + GVEl(CL) * THJNTEGRAL ) ) / OMEGA 

a) In the equation for qjemp. the term "GP_ALTITUDE( 1 .3,0)" Is Incorrect. 

b) The equation for qjemp has unbalanced parentheses making it ambiguous. 

c) q_over_omega Is Incorrect because the term " GVEl(CL) * TEJNTEGRAL" Is in the equation twice. 

10) The variable TEJJMIT Is not included In its limit processing, a local variable is used instead. 
This leaves the variable. TEJJMIT. unchecked when processing Is completed for this P-Spec. 

11) In reference to the description for clearing the pitch, yaw. and thrust error based on 
AE_SWITCH: 

if (AE_S WITCH == off) 
pitch_crror = 0. 
ynw_error = 0. 
tlmist_crror = 0. 

This added functionality Is not defined In the Spec. 

12) The following IF blocks have closing ELSE branches where processing to be performed Is 
inadequately described. I he instructions arc vaguely to "Give error message." 

a) The IF structure for calculating the TEJNTEGRAL. 

b) The IF structure for determining pitch, yaw and thrust error. 

c) The IF structure for determining AE_CMD. 

1 3) Unnecessary bounds checking for Cl IUTE_RELEASED. 

14) Unnecessary introduction of temporary variable. "Int cmd". when determining the value of 
AE_CMD. 

’5) The rounding step for AE_CMD is missing. 
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GCS Action Report 


page I nl 2 


1. AR #: 

2. Planet: 


4. Respondent & Role: 

10.1 

Fluto 


Angellatta, P..K. Erogrammer 

5 . Artifact Identification: 


Configuration Item: 

X Design Description 
Source Code 
Executable Object Code 

Support Documentation 
Other 

Plut.c Design Description 
P-Spec 2.1 AECLP 


6. Description of Action 


1) In accordance with formal mod. 2.2-28 the range checking for the data 
element AE_SWITCH is unnecessary. The range checking fqr the data 
element AE_SWITCH has been removed from P-Spec 2.1 AECLP . 

2) An algorithm for determining the value of data element AE_TEMP has 
been inserted into the design. 

3) The algorithm for determining the value of data element PE_INTEGRAL 
has been modified such that: 

a) the correct element of GP_VELOCITY is referenced; 

b) An absolute value operation is performed as stated in the GCS Soft- 
ware Requirements; and 

c) The local data element "theta" has been removed from the design. 

4) The unnecessary range checking for the data elements AE_TEMP and CON- 
TOUR_CROSSED have been removed from P-Spec 2.1 AECLP. 

5) The computation of " limit ing_pitch_error" (renamed to 

"pitch error limit") has been modified and is now expressed by a sin- 

gle equation. Likewise, the computation of "limiting yaw error" (re- 
named to "yaw error limit") has been modified and is now expressed by 

a single equation. 

6) a) The indexing notation for the data element A_ACCELERATION has been 
modified to clearly indicate which element is being referenced. 

b) References to the data element GP_ALT I TUDE have been modified to be 
consistent with the data element declaration (ie. a single diminsion 
array) . 

c) Range checking has been added where appropriate for elements of the 
the data elements GP_ATTITUDE and GP_VELOCITY. 

7) The assignment of the data element TE_LIMIT based on the value of data 
element AE_TEMP has been removed from the design. 

8) Due to the mathmatical symbols involved, the derivation of the equa- 
tion specifying the computation for TE_LIMIT will be included in the 
appropriate section of the design "introduction". 


7. Was the action related to another action(s)? Yes AR«(s) 

X No 

Do not know 
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Action Report Continuation 


page 2 of 2 

a. Report #: 

10.1 

b. Notes/Explanation (Please reference appropriate section number): 

9) The computation of TE_LIMIT has been corrected. 

a) The data element GP_ATTITUDE (1 , 3, 0) has been substituted for the 
data element GP_ALT I TUDE (1,3,0) . 

b) The parentheses in the expression of "q" (formerly "q_temp") are 
now balanced. 

c) The term "q_over_omega" has been removed from the computation of 

TE_LIMIT. ' 

10) Range checking for the data element TE_LIMIT is included where ap- 
plicable . 

11) The cited description has been removed from the design. 

12) The "Give error message" branches cited have been removed from the 
design . 

13) In accordance with formal mod. 2.2-28 the range checking for the 
data element CHUTE_RELEASED has been removed from P-Spec 2.1 AECLP . 

14) The algorithm for determining the value of data element AE_CMD has 
been modified and the data element "int_cmd" removed from the de- 
scription . 

15) Although implicit in the original design, the algorithm for deter- 
mining the value of the data element AE_CMD has been modified to 
explicitly express the "rounding" operation. 
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GCS Problem Report 


page 1 of 2 


1 l.PR#: 

2. Planet: 

3. Discovery Date: 

11 

i 

Pluto 

Oct. 15, 1993 


4. Initiator & Role: 

Inspcctor/Quach and Bcchcr 


5. Activity at Discovery: 

* Activity 

Development Phases | lra^|^^|RQ^_RS__tj^ L_S- 


Design 


Code 


Unit Testing 


Functional 


Structural 


Subframe Testing 


Frame Testing 


Top-Level Simulator 
Integration Testing 



6. Description of Problem: 

The following are Inconsistencies and deficiencies for the CP (P-Spec.. 2.4) and CALCULATE CRC-16 (P- 
Spec. 2.19) in the Pluto Design Description that need to be addressed. 

COMMUNICATIONS PROCESS P-Spec 2.4 deficiencies: 

1) The following variables are listed as Inputs /outputs to the P-Spec but are not listed In the GCS 
Spec: 

a) Inputs: 

C STATUS, CL, AE SWITCH, CHECKSUM. FRAME_BEAM_UNLOCKED, 

FRAME ENGINESJGNITED, INTERNAL_CMD. ITI I_FRAME_5, ITH_FRAME_2, RE_SW1TCH, 
TDLRSP_SWITCH. TD SP_SWITCI I , TE_LIMIT, THETA 

b) Outputs: 

NBYTES, BYTE_PAC KET. 

2) According to DFD-2, bubble 2. 19(CALCULATE CRC-16) only has data flows to and from bubble 
2.4(CP). Tills violates Structure Analysis DFD conventions as extended by Hatley and Plrbhal for 
real time systems. It also results In a P-Spec referencing another P-Spec as Implied by the call 
CALCULATE CRC-16". 


7. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


Support Documentation 
Other 


Configuration Item: 

Pluto Design Description 

_ V > '6p<?C and 


8. Test Case Identification: 


9. History Lof 
Date To 

Dale From 

Person 

Comments 

ARM 

/.I A )<?<-! 


Angellatta 


II- / 



V tol4<4 

‘ Quach 



ieh M<A 

ijJlM 

- ^ 7 

Hayhurst 





(J 




10. Total M of Changes: c2£L 


1 1 . Total M of No Changes: 


12. Initiator Signature A Date 
Original Signed by 


6 - 4 - % 


13. SOA Signature A. Date 

^Original Signed by 
"Kelly Hayhurst 


Patrick Quach ^ 

* Activity: uk - ucsign kcvicw; CR - Code Review; RC - Reading Couc; to - Kcauing apccincauon; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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Problem Report Continuation 


page _ 2 _ of JL 

a. Report #: 1 1 

b. Notcs/Explanation (Please reference appropriate section number): 

3) Concerning the table which spans from the bottom of page 3 to page 4 

a) The notation used for Inlt_sample_mask_sub_fr_l and 2 and 3 Is not explained. 

b) The Intent of the table is not very clearly explained and Is Incomplete, 
cj Some variables are missing. 

4) For subframe 1 and the case where Its llh_frame_2 and not llh_frame_5: 

a) K_MATRlX's mask bit Is not set. 

b) When It Is packed, all elements are sent contrary to Spec. 

5) For subframe 1 and the case where Its ltli_frame_2 and lth_frame_5: 
the data mask bits for K_ALT and K_MATR1X are not set. 

6) In the processing for subframe 2, the description for packing the array variable "GP_ROTATION" 
does not Indicate that only the diagonal elements from the matrix are to be packed (as stated In the 
Spec.). 

7) There Is no description for the special treatment of history variables as provided In the Spec. 

8) In each case where a specific list of variables Is given to be packed, the lists startwlth a comment 
such as: 

subframe 1 variable 
subframe two's variables 
subframe three's variables 

It Is not clear whether this comment Is In the list to Indirectly reference the actual variables 

9) A description for how the Information Is organized In the packet to be transmitted Is necessary. 
Vague references to byte placements are Inadequate. 

10) In reference to the IF-ELSE block which handles the different subframe counters, the variable 
"sub_frame_counter" Is used but not specifically defined. 

1 1) The description for deriving a value for the variable "NBYTES" Is not clear. 

12) The last ELSE block In the subframe checks accommodates the case where the subframe counter 
Is Invalid, this Is not required by the Spec. 

13) The calling syntax and argument usage of the process CRC-16 Is not clear. 

14) The description for packing the CRC-i6 checksum Into the "BYTE_PACKET' Is Incorrect since the 
CRC-16 Is only 16 bits. 

■ 15 ) C_STATUS Is set to healthy at the end of the P-Spec. Contrary to the Spec, which requires It to be 
set prior to calculating the CHECKSUM and prior to loading C_STATUS Into BYTE_PACKET and 
PACKET. 

CALCULATE CRC-16 P-Spec 2.19 deficiencies: 

16) Concerning the description to generate the CRC table: 

a) The term "logical shift" Is used to describe operations to build the CRC table. A brief description 
of what Is meant by logical shift may be helpful. 

b) The CRC table Is Indicated to have 16 entries, but the Instructions for completing the table are 
only applied to 4 entries. An explanation Is necessary. 
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Problem Report Continuation 


page _S_ of _1_ 

a. Report #: 1 1 

b. Nolcs/Explanation (Please rcrcrcncc appropriate section number): 

17) Concerning the description for calculation the checksum: 

a) The description for calculating the checksum Is very vague. 

b) In stepl. the term "llrst" Is used In the checksum calculation; but the byte ordering of the 
variable BYTE_PACKET Is not specified. It Is not clear which byte should be used. 

c) In step 3. the instruction does not specify where the result of the operation Is to be placed. 
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5. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


f>. Description of Action 


GCS Action Report 

page I of 3 


4. Respondent & Role: 

Angellatta, R.K. Programmer 


Configuration Item: 

Support Documentation pluto Design Description 

0lhcr P-Spec 2.4 CP 


2. Planet: 

3. Date of Action: 

Pluto 

June 7, 1994 


In addition to addressing the items on PR #11, P-Spec 2.4 CP has been 

updated to comply with Formal Modification 2.3-2 which addresses func- 
tional unit scheduling. 

1) a) The following data elements have been removed as inputs to P-Spec 
2.4: CL, AE_SWITCH, CHECKSUM, FRAME_BEAM_UNLOCKED , 

FRAME ENGINES_IGNITED, INTERNAL_CMD , I TH_FRAME_5 , ITH_FRAME_2, SWITCH, 
TDLRSP SWITCH, TDSP_SWITCH, TE_LIMIT, and THETA. Note, the data ele- 
ment C STATUS remains as input to P-Spec 2.4 as it is an valid input, 
b) The” following data elements have been removed as outputs from P- 
Spec 2.4: NBYTES, BYTE_PACKET . 

2) The processing specified in P-Spec 2.19 CALCULATE CRC-16 has been 
moved to P-SPEC 2.4 CP and P-Spec 2.19 removed from the design. 

3) The table in question has been removed from the P-Spec. The intended 
information presented in the table is now presented in the description 
of the organization of the various data fields. 

4) Reporting of the data element KJMATRIX is now consistent with the 
specifications. The appropriate bit in the data mask is set and only 
the appropriate elements of the data element K-MATRIX are reported. 

5) The bit associated with the data element K_ALT in the data mask is set 
when generating a data packet for reporting the completion of subframe 
one . 

6) The design has been modified to explicitly show the "packing" of the 
data element GP_ROTATION. 

7) The design has been modified to explicity show the "packing" of every 
data element into data packets. There is no abiguity as to which data 
elements are reported and which are not. 

8) The cited statements have been removed from the design. 

9) See item number 7 above. 


7. Was the action related to another action(s)? 


Yes ARw(s) 
X No 

Do not know 
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Action Report Continuation 


page 2 <»f 3 

a Report #: 

11.1 

h. Notes/Explanation (Please reference appropriate section number): 

10) Reference to the data element "sub_frarae_counter" has been removed 
from the P-Spec. 

11) The data element NBYTES has been removed from the design. 

12) The control structure of the algorithm has been modified and the 
cited "ELSE" statement removed. 

13) Documentation has been added for the CRC-16 function. 

14) See item number 7 above. 

15) The requirement to set the status of the communications gear has 
been moved to the beginning of the processing. 

16) The function for computing the CRC has been redesigned and now in- 
cludes a reference and description of the algorithm employed. 

17) See item 16 above. 

While implementing the changes documented above, several modifications 
to other portions of the design were necessary. 

The originial P-Spec 2.4 incorrectly contained an output data flow named 
PACKET which connected to anff external terminator named TELEMETRY 
TRANSMITTER. The actual destination of the output data flow PACKET 
is the data store EXTERNAL. The context diagram GCS, DFD 0 
INI T_RUN_GC S , and DFD 2 RUN_GCS have all been modified to express the 
correct destination of the data flow named PACKET. 

The data store named EXTERNAL has been modified to explicitly reference 
the appropriate data elements. Previously, EXTERNAL referred to the 
individual data elements indirectly by referencing named data flows 
which contained the data elements. 

DFD 2 RUN GCS contained a data store named SUBFRAME_COUNTER_STORE which 
supplied bubble .4 with the control signal SUBFRAME_COUNTER . The 
data element SUBFRAME_COUNTER was added to the data flow named 

COMM EXT IN . Bubble .4 now has access to the data element SUB- 

FRAME_COUNTER via the data flow COMM_EXT_IN. The data store SUB- 
FRAME COUNTER_STORE and the associate flow have been removed from DFD 
2 RUN~GCS . ~ 

DFD 2 RUN GCS had a data flow named COMM_RP_IN containing a single input 
to bubble .4. The data flow has been renamed to COMM_SYNC_PATTERN. 
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Action Report Continuation 


page 3 


of 3 


;i Report #: 

11 . 1 

b. Notes/Explanation (Please reference appropriate section number): 

DFD 2 RUN GCS had a data flow named COMM GS IN containinct a single input 

to bubble .4. The data flow has been renamed to C_STATUS . 

DFD 2. RUN_GCS contains a data flow named COMM_GS_IN connecting the data 

store GUIDANCE STATE to bubble . 4 . The following data elemnents have 

bee removed from COMM_GS_IN when addressing item 1 above*: AE SWITCH, 
CL, FRAME_BEAM_UNLOCKED , FRAME_ENGINES_IGNITED , INTERNAL CMd 7 
RE_SWITCH, TDLRSP SWITCH, TDSP_SWITCH, TE_LIMIT and THETA. 

The processing formerly specified in P-Spec 2.19 Calculate CRC-16 is now 
specified within P-Spec 2.4 CP. Bubble .19 representing P-Spec 2.19 
and the associated data flows have been removed from DFD 2 RUN GCS. 
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GCS Problem Report 


page 1 of 3 


' l.PRH: 

2. Planet: 

3. Discovery Dale: 

i “ 

Pluto 

Oct. 15. 1993 


4. Initiator & Role: 

Inspcclor/Quach and Bcchcr 


5. Activity at Discovery: 

Development Phases 


Design 


Code 


Unit Testing 


Functional 


Structural 


Subframe TestinR 


Frame TcstinR 


Top-Level Simulator 
InteRration TestinR 



6. Description of Problem: 

The following are Inconsistencies and deficiencies for the GP P-Spec. 2.7 In the Pluto Design Description 
that need to be addressed. 

1) The comment which lists all the functions of the P-Spec. Is Incomplete. 

2) Local "real" variables declared with Inadequate precision. 

3) The description for shifting variables with history dimension uses ambiguous notations. Further, 
G_ROTATION Is incorrectly listed as having a history dimension. 

4) Concerning the description of calculations for GP_A1T ITUDE, GP_VELOCITY, and GP_ALT1TUDE. 

a) A mixture of array Index notations Is used In describing malting It unclear exactly which 
element of the arrays are Involved In the calculations. 

b) The assignment operator, "=", Is not used consistently with Its definition. 

c) The description of calculation does not accommodate for solving the equations simultaneously 
as indicated In Appendix C. 

5) The description for the set up of the GP.ROTATION MATRIX is Inadequate. 


7. Artifact Identification: 

X Design Description 
_ Source Code 

Executable Object Code 

Support Documentation 

Ollier 

Configuration Item: 

Pluto Design Description 


8. Test Case Identification: 



Person 

Comments |( 


■VJfRnH 


Angellatta 


VJrJMHI 


WBPsmm 

_ Quach i 



tf/AplW 


Hayhurst 



10. Total # of 

. . 

Changes: 13 

1 1. Total ft of No Changes: 


17 Initintnr Signature A Date 


20 % 


Original Signed by 
"’Kelly Hayhurst 


diHohJ 


Original Signed by 

* Acuiuyk DR - Design Review; CR - Code Review; RC - Reading Cone; to - Kcaaing apccmcauon; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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Problem Report Continuation 


page _2_ of _1_ 


a. Report if: 12 


b. Notcs/Explanation (Please reference appropriate section number): 

6) In reference to range checking: 

a) GP PHASE Is unnecessary checked for limits. 

b) GPALTITUDE lower limit check ts Incorrect 

c) Limit checking for the following Is missing: 

GP ATTITUDE, 

A_ACCELERATION, 

AR ALTITUDE. 

G ROTATION. 

TEJNTEGRAL, 

GP ROTATION 


b) 

c) 


d) 


7) Concerning the IF block for GP_PIIASE = 1: , r , 

a) The data element "tnow" Is used in the first IF block for GP_PHASE but not defined. 

FRAMEJENG1NESJGNITED limit check Is unnecessary and Incorrect. 

Limit checks for the following are unnecessary: 

AE TEMP 

CHUTE_RELEASED 
TDS_STATUS 
TD SENSED 

Limit check for GP_VELOCITY Inside this If block Implies that limits for this variable Is only 
checked for 1 GP_PHASE. 

8) The combined processing of engine on/olT status determination and terminal descent phase 
determination makes requirements from the GCS Spec very difficult to trace. The processing Is 
also Incorrect. 

9) Concerning the description for pre-lndexing Into the CONTOUR_VELOCITY array, 
a) The description does not give any indication into why it Is being done. 

The CONTOUR_VELOCITY array is the wrong one to Index Into. 

No algorithmic solution is given. 

The description uses the variable "size" which Is not declared. 

No bounding limits are given for the binary search. 


b) 

c) 

d) 

e) 


10) A description for proportional extrapolation and the pseudo-code that follows Is not clear. 

1 1) Concerning the description for calculating the VELOCITY ERROR: . .. „ 

a) The description Is nested Inside a condition when It should be performed uncondltiona y. 

b) The description for computing VELOCITY_ERROR Is Incorrect. 

12) Limits checking for CL is unnecessary. 

13) In determining which control laws to use, 

a) Ambiguous notation used to index into GP.VELOCITY array , . , ,, 

b) The condition "VELOCITY_ERROR > 0” In the IF statement a convoluted way of specifying the 
same thing as the Spec. It is difficult to trace to the Spec. 

c) The variable "optimal_velocity" Is used here but no value has been previously assigned to it. It 

has not even been declared. 

14) Tile note describing the GP.ATrrTUDE. GPJVELOCITY. AND CP.ALTITUDE references section 2.7 
of the Spec, for variable definitions. The variable definitions are no longer In section 2.7 ol the 
Spec. 
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Problem Report Continuation 


page _2L of _3_ 
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GCS Action Report 


page I of 2 


1. AR«: 

2. Planet: 


4. Respondent & Role: 

12.1 

Pluto 


Angellatta, R.K. Programmer 

5. Artifact Identification: 


Configuration Item: 

X Design Description 
Source Code 
Executable Object Code 

Support Documentation 
Other 

Pluto Design Description 
P-Spec 2.7 GP 


6. Description of Action 


1) The initial comment which enumerates the responsibilities of this 
functional unit has been modified to include all of responsibilities 
of GP. 

2) Since this is a design, and not code, references to the data types 
have been removed from the P-Spec. 

3) The "rotate variables" algorithm has been replaced and now explicitly 
describes the concept of "shifting." 

4) The description for computing the current values of GP_ATTITUDE, 
GP_VELOCITY, and GP_ALTITUDE has been rewritten. 

5) The description of the construction of GP_ROTATION is now very ex- 
plicit . 

6) a) Range checking for GP_PHASE has been removed from the P-Spec. b) 

The lower limit for GP_ALTITUDE has been corrected, c) Range checking 
for the appropriate data elements has been specified. 

7) The cited "IF block" has been totally respecified. 

8) In conjuction with item 7, the processing of the engine on/off has 
been totally respecified for cl^arity. 

9) The computation of the "optimal_velocity " has been completely respeci- 
fied. The interpolation and expolation algorithms are presented. 

10) See item 9. 

11) The computation of the velocity error has been completely respeci- 
fied. 

12) Range checking for CL has been removed from the P-Spec. 

13) The processing which determines which set of control laws to use has 
been completely respecified. 


7. Was the action related to another action(s)? Yes AR#(s) 

X No 

Do nol know 
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Action Report Continuation 

page 2 of 2 

a. Import #: 

12.1 

b. Notes/Explanation (Please reference appropriate section number): 

14) The notes describing the processing of GP_ATTITUDE, GP_VELOCITY, 
and GP_ALTITUDE have been rewritten and moved to the appropriate sec- 
tion of the "Design Overview." 

15) See item 14. 
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GCS Problem Report 



2. Planet: 

3. Discovery Date: 

4. Initiator & Role: 

13 

Pluto 

Oct. 15, 1993 

Inspcclor/Quach and Bcchcr 


5. Activity at Discovery: 


* Activity 


Development Phases 

II dr 

CR 

RC 1 RS 

TOR 

TCR 1 I CC 1 TCE I 

R 

0 

Design 

lx 





Code 

■■ 






Unit Testing 

r“ 










Functional 

■ 









Structural 









Subframe Testing 









Frame Testing 









Top-Level Simulator 
Integration Testing 










6. Description of Problem: 


The following are deficiencies In the Data Dictionary, Data Flow Diagrams, and Process Activation Tables 
of the Pluto Design Description. 


DATA DICTIONARY deficiencies 
1) Incomplete/Incorrect aggregate data flow 

a) The actual data elements In the EXTERNAL data store do not agree with those In the Spec.. 

b) COMM_EXT_IN Is missing the variable SUBFRAME_COUNTER. 

c) CHUTE_RELEASE data/control flow contains data not Included In the Spec. The only field 
specified In the Spec for this data flow Is CHUTE_RELEASED. 

d) COMM GS IN contains C_STATUS and CL which are not Inputs to CP. 

e) 1NIT_GS_0UT 

- has 2 extra data flows not defined as part of GUIDANCE_STATE data store In the Spec. 
They are TDLRSP_SWITCI 1 and TDSP_SWITCH. 

- Is missing tire variable CL 

11 GUIDANCE_STATE_DATA has extra variables TDLRSP_SW1TCH and TDSP_SW1TCH 


7. Artifact Identification: 

X Design Description Support Documentation • Configuration Item: 

_ Source Code Ollier Pluto Design Description 

___ Executable Object Code 


8. Test Case Identification: 



KHE9I 

Person 

Comments 

ARtt 

rniBiunm 


Angellatta 



■EM 

hi 


Quach 






Hayhurst 









10. Total # of Changes: t? 


1 1 . Total ft of No Changes: 


12. Inilialnr Stonnlnrc. Hr Dnlr*. 
Original Signed by 


6 

- 2.7-^ 

13. SOA Signature & Date 
Original Signed by 


Patrick Quach Kelly Hayhurst ' 

* Activity: DR - Design Review; CR - Code Review; RC - Reading Couc; to - Reading Specification; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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Problem Report Continuation 



a. Report#: 13 


b. Notcs/Explanation (Please reference appropriate section number): 


Data Store Inconsistencies: 

a) Extra variables In GUIDANCE_STATE data store: 

CHUTE RELEASE 
TDLRSP SWITCH 

TDSP SWITCH , 

b) The GENERATE_SEQUENCE_PARMS store Is not defined and not used. 

Incorrect/lncomplete DATA DICTIONARY definitions 

a) TDLR_ANGLES . "PI" is used In the RANGE field but not defined. 

b) THETA, "PI" Is used In the RANGE field but not defined. 

c) AR_FREQUENCY. the RANGE upper value "2.45**9" is Incorrect. 

d) BYTE_PACKET is defined to be 188 of integer* 1 which does not match its usage as a 
temporary variable for PACKET which Is 256 of lnleger*2 

e) CHECKSUM definition Is not complete 

0 INIT_END_GCS - If a control flow can only deliver one value, why have It. 

g) INIT_EXT_OUT - inadequate description! 

h) NBYTES - Inadequate description! 

0 RENDEZVOUS_CNTL - Inadequate description! 

J) RUN_GCS - inadequate description! 

k) ITH_FRAME_2 - inadequate description! 

l) ITH FRAME 5 - Inadequate description! 

m) INlflSUBFRAME_COUNTER - set to "1" with no explanation. 

n) START_GCS - Inadequate description leaves PAT open for Interpretation. 


Unused data flows: 

AECLP DONE, 

ASP DONE, 

CP_DONE. 

GP.DONE, 

RECLP DONE. 

SP DONE, 

TDSP_DONE, 

EXTERN AL_OLD, 

INIT_GCS, 

RUN GCS, 

SENSOR OUTPUT_OLD , 
TDLRSPjS WITCH , 

Unnecessary renaming of another data 
ACCEL_EXT_IN, 
ACCEL_GS_OUT, 
ALT_RAD_RP_IN, 

ALT RAD_SO OUT, 

ax_eng_ext_out. 

CHUTE REL GS_OUT, 
COMM_RP_IN, 

GUIDE_EXT_IN. 

TD_GS_OUT, 

TD LND RAD SO OUT 


ARSP_DONE 
CLP DONE 
CRCP DONE 
GSP.DONE 
RENDEZVOUS 
TDLRSP DONE 
TSP DONE 

GUIDANCE_STATE_OLD 
GENERATE_SEQUENCE_PARMS 
RUN_PARAM ETERS_OLD 
COMM_EXT_OUT 
TDSP SWITCH 


ACCEL_GS_IN 
ACCEL_SO OUT 
ALT_RAD_SOJN 
AX_EN G_EXT_I N 
AX ENG_SO_OUr 
COMM GS OUT 
EXTERNAL DATA 
ROL_ENG EXT_OUT 
TD LND RAD SO IN 
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Problem Report Continuation 


page 3 of 4 

a. Report#/: 13 

b. Notcs/Explanation (Please reference appropriate section number): 

6) END_GCS control flow In no longer an output of GP. 

7) SUBFRAME_COUNTER_STORE Is unnecessary. The control flow emanating there from Is 
already Included In COMM_EXT_IN. 

8) It Is not clear from available documentation how the following stores are used: 

•END GCS STORE 

*GP HASJRUN STORE 
•RENDEZVOUS CNTL_STORE 
*SUBFRAME_COUNTER_STORE 


CONTEXT DFD deficiencies 

1) In the context DFD. the data for FRAME COUNTER and SUB_FRAME_COUNTER are not shown 
returning to the external entity GCS_SIM INIT AND RENDEZVOUS. These data nows are 
missing from the next level DFD. 

2) The data flow INITIALIZATION_DATA contains a control flow variable. 


DFD 2 deficiencies 

1) Some bubbles have Identical data flow in and out of the bubbles. This violates SA conventions 
The specific data flows are: 

Bubble 2.12: EXTERN AL_DATA. FRAME_COUNTER 
Bubble 2.13: RA\V_SENSOR_DATA. RAW SENSOR_EXT_OUT 
Bubble 2.14: RUN_PARAMETER_DATA. INlT_RP_OUT 
Bubble 2.15: GUIDANCE_STATE_DATA. lNIT_GS_OUT 
Bubble 2.16: CHUTE_RELEASE 
Bubble 2.17: AE_RE_CMDS, ENG1NE.DATA 

2) Bubble 2. 18. COPY CONTROL DATA, does not perform any discernible data processing. It is 
extraneous. 

3) In DFD-2 It is not clear that the PACKET data flow goes into the GU1DANCE_STATE data store 
as indicated by the Spec 

PAT INIT_RUN_GCS deficiencies 

1) The second line shows bubble numbers but can easily be confused as additional execution 
orders to control execution. The same thing occurs in the PAT for DFD-2. 

2) The fifth line shows that the order of activation of GENERATE_SEQUENCE_PA_RMS and 
RUN_GCS doesn't matter; however, the IN1T_END_GCS DFD shows that for a given frame, 
GENERATE SEQUENCE PARMS must be executed before RUN_GCS because the variables 
ITH_FRAME 2 and 1TH_FRAME_5 flow from GENERATE_SEQUENCE_PARMS to RUN_GCS. 
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page 4 of 4 


a. Report fi: 13 


b. Notes/Explanation (Please reference appropriate section number): 


PAT RUN_GCS deficiencies 

Tire process "COPY CONTROL DATA" Is missing from tills PAT leaving Its activation order 
unknown. ■ 

For the cases where subframe_counter = 1, the PAT Imposes a constraint on processes that do 
not depend on TSP. 

For the cases where subframe_counter =3, the PAT Imposes an order constrain on execution of 
AECLP, and RECLP. 

The SUBFRAME_COUNTER Is assign a new value In this PAT. This Is Incorrect. 

The control variables ITH_FRAME_2 and 1TH_FRAME_5 should be removed to reflect new 
changes In the Spec. Process activation order should also be changed accordingly. 

The simulator rendezvous Is activated at the end of each subframe. It Is however missing from 
the activation order In the table. 

In the column GP_HAS_RUN, use of the "DONT CARE" value Is not clearly Interpretable. 

The processes SEND CHUTE RELEASE COMMAND and SEND ENGINE DATA do not perform 
any data transformation and hence should be removed from the activation list. 
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I. AR#: 
13.1 

2. Planet: 
Pluto 

3. Date of Action: 

June 24, 1994 

4. Respondent & Role: 

Angellatta, R.K. Programmer 

5. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 

Support Documentation 
Other 

Configuration Item: 

Pluto Design Description 


6. Description of Action 

Data Dictionary deficiencies 


1) The four data stores EXTERNAL, GUIDANCE_STATE, RUN_PARAMETERS , and 
SENSOR_OUTPUT has been modified as necessary to be consistent with the 
GCS Software Requirements. The named data flows connecting the four 
data stores with processes have been modified to include only the nec- 
essary data items. All spurious data stores have been removed from 
the design. 

2) Refer to item 1 above. 

3) A value has been assigned to "PI" where necessary. The value for the 
upper limit of the data element "AR_FREQUENCY" has been modify. The 
data elements cited in d) through n) have been removed from the de- 
sign . 

4) The cited unused data elements have been removed from the design. 

5) All of the cited data/control flows 'renamed' a single data element 
exiting in one of the four data stores. In such cases, the 'renaming' 
data/control flow was removed from the data dictionary and replaced in 
the DFDs by the single element it represented. 

6) The ' END_GCS' control flow serves as a 'halt' signal for the implemen- 
tation and does originate from the process named 'GP'. 

7) Refer to item 1 above. 

8) Refer to item 1 above. 

Context DFD deficiencies 

1) The data element FRAME_COUNTER does not explicitely appear in the 
modified context DFD. The data element SUB_FRAME_COUNTER has been 
removed from the design. 

2) The data flow INITIALIZATION_DATA has been removed from the design. 


7. Was the action related to another action(s)? Yes AR#(s) 

X No 

Do not know 
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Action Report Continuation 


pngc 2 of 2 

a. Report #: ™~ 

13-1 

b. Notes/Explanation (Please inference appropriate section number): 

DFD 2 deficiencies 

1) All of the cited processes have been removed from the design. 

2) The cited process has been removed from the design. 

3) The design has been modified to clearly depicted the dat'a element 
'PACKET' resides in the data store 'GUIDANCE STATE.' 

PAT INIT_RUN_GCS deficiencies 

1) The second line indicating the process numbers is an appropriate 
process specification for a PAT under Teamwork. Note, however that 
they have been removed from the modified design. 

2) The process ' GENERATE SEQUENCE_P ARAMS ' has been removed from the de- 

sign. 

PAT RUN_GCS deficiences 

1) The process ' COPY_CONTROL_DATA' has been removed from the design. 

2) It is inherent in the design process to impose constraints upon the 
abstractions presented in the requirements specifications. There is 
no deficiency indicated in item 2. 

3) Refer to item 2 above. 

4) The design has been modified and does not assign a value to the data 
element ' SUBFRAME_COUNTER' . 

5) The control flows ' ITH_FRAME_2' and ' ITH_FRAME_5 ' have been removed 
from the design. 

6) The design has been extensively modified to indicated to proper acti- 
vation of the process named ' GCS_SIM_RENDEZVOUS , ' the simulator ren- 
dezvous processing. 

7) The control flow 'GP_HAS_RUN' has been removed from the design. 

8) The processes ' SEND_CHUTE_RELEASE_COMMAND' and 'SEND ENGINE DATA' 
have been removed from the design. 
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GCS Problem Report 



2. Planet: 


3. Discovery Date: 
Jun. 27, 1994 


4. Initiator & Role: 

Designcr/Angcilatla 


5. Activity at Discovery: 


* Activity 


Development Phases 

Design 

Code __ 

Unit Testing 

Functional 

Structural 

Subframe Testing 

Frame Testing 

Top-Level Simulator 
Integration Testing 


R 

O 


1/ 
















6. Description of Problem: 


o?.3-i2 


lits hail^ecn changed by Formal Modification 2.3-2. The functional units ARSP 


The scheduling algorithm for functional units ha« been changed by Formal Modification 2.3-2. 
and TDLRSP must be modified so that they are consistent with the new scheduling requirements. 


7. Artifact Identification: 

X Design Description 

Source Code 

Fxecutnbic Object Code 


8. Test Case Identification: 


Support Documentation 
Other 


Configuration Item: 

Pluto Design Description 

1 I. CTl)Lg.< 





1 1 . Total ft of No Changes: 


2. Initiator. Sienatiirc A Dn/r. P SOA Signature A Date 

| • Original Signed by Jchc Ztf jtfVj Original Signed by 

4 At Rob Angellatta lie Review; RC - Rending Code: RS - Rending Kelly Hayhurst 

ICC - i - i cm v. use Execution; R - Rcgicssinn; () - ( )llier. 
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GCS Action Report 


page 1 of i 


1. AR#: 

2. Planet: 

3. Date of Action: 

4. Respondent & Role: 

14 . 1 

Pluto 

June 28, 1994 

Angellatta, R.K. Programmer 

5. Artifact Identification: 


Configuration Item: 

X Design Description 
Source Code 
Executable Object Code 

Support Documentation 
Other 

Pluto Design Description 
ARSP and TDLRSP 


6. Description of Action 


Formal Modification 2.3-2 changed the functional unit scheduling algorithm. This has a direct impact 
upon the processes ARSP and TDLRSP, which had been modified prior to the issuance of Formal Modifica- 
tion 2.3-2. 

Changes to ARSP. 

All references to "odd" and "even" frames and "normal" and "alternate" processing have been removed 
from the P-Spec. The control statement which formerly detennined "nonnal" and "alternate" processing has 
also been removed from the P-Spec. The algorithm for computing the current altitude by Fitting a polynomial 
to the four previously computed values for the altitude had been optimized to use only two of the previous 
values. This algorithm has been modified to use all four previous values. A few minor syntax chanages were 
made in order to make the syntax of this P-Spec consistent with more recently edited P-Specs. 

Changes to TDLRSP. 

All references to "odd" and "even" frames and "normal" and "alternate" processing have been removed 
from the P-Spec. The control statement which formerly determined "normal" and "alternate" processing has 
also been removed from the P-Spec. 


7. Was the action related to another action(s)? Yes AR#(s) 

X No 

Do not know 
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GCS Problem Report 


2. Planet: .3. Discovery Date: 4. Initiator & Role: 

Pluto July 13, 1994 Inspcctor/Quach and Bcclicr 


3. Discovery Date: 
July 13, 1994 


page I of _2_ 


5. Activity at Discovery: 

* Activity 

Development Phases DR | CR | RC I RS | TRR ( ICR | ICC I TCE | R O 

Design 

Code I ^ 

Unit Testing | | | 

Functional 

Structural L 

Subframe Testing 

Frame Testing 

Top-Level Simulator ^ 

integration Testing 


6. Description of Problem: 

The following arc inaccuracics/dcficicncics for tire functional units In the sensor processing subframe. 

ARSP, P-Spcc 1.2 

1 ) FRAMF_COlINTF.R is not an input to this process. This is probably due to an error in tlm 
specification. 

2) Range Checking is not performed for AR_ALTI' TUDF. history variables that arc used in the Divided r 
Difference calculation. 

3) It is not necessary to use FORTRAN floating point notation for a constant in the design. 

ASP P-Spec 1 .3 

1 ) The check made for negative arguments under the square root is insufficient. 


7. Artifact Identification: 



_X_ Design Description 

Support Documentation 

Configuration Item: 

Source Code 

Other 

Pluto Design Description, P-Specs 1.2, 

Executable Object Code 


1.3, 1.5, and 1.7 

8. Test Case Identification: 


Date From 



WBmsBMWBimmL 


m 


10. Total # of Changes: 


12. Initiator Sipnainrc & Dm** 



1 1 . Total if of No Changes: 


13. SOA Sic nature & Date 
7 - Z I ~ *1 Original Signed by 


_Original Signed by | Original Signed by r ll&\j()<J 

Patrick Quach Kelly Hayhurst 7 / 7 7 

* Activity: UK - Design Review; CR - Code Review; RC - Reading Cone; K.'j^-Kcanmg ,'tpccincaiion; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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Problem Report Continuation 


page 2_ of _2_ 


a. Report #: 15 

b. Noles/Explanation (Please reference appropriate section number): 

Section 6. Description or Problem (continued): 

2) Range Checking is not performed for A_ACCELliRATION history variables that are used in the mean 
and standard deviation calculation. , 

TDLRSP, I’-Spcc 1.5 

1) The design has not explicitly stated the number of radar beams. 

In reference to the start of the DC) loop: 

do (for each radar beam i) 

2) Concerning the set of IF statements for determining radar beam states (pg. 4) The design meets all the 
requirements but has extra branches that arc not specified In Ibc Requirements. 

« 

3) The setting of the orr-diagonal elements or K_MATRIX to zero is not necessary. 

4 ) Below the table for determining process beam velocity, equation b) has a typo for the operator in 
front of the term b(4). This also occurs in case #1 5 of the subsequent case statement. 


I SP, P-Spcc 1 .7 

\) Concerning the Lower parabolic function (pg. 3): 

There Is a typo In the substitution of "h" Into the parabolic equation. Either there Is an extra set of parcti. 
or the sign after the M3 should be a "+" 


2 ) 


There is a typo in the first equation in the 
the "y = 4*p..." should be "y = l/(4*p)..." 


derivation for the upper parabolic region. Particularly, 



GCS Action Report 


page 1 of 2 


1. AR#: 

2. Planet: 


4. Respondent & Role: 

15.1 

Pluto 


Angellatta, R.K. Programmer 


5. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


Support Documentation 
Other 


Configuration Item: 

Pluto Design Description 
P-Specs 1.2, 1.3, 1.5, and 1.7 


6. Description of Action 
; ARSP 

1) The data element FRAME_COUNTER has been removed from the input list 
to the P-Spec ARSP and from the data flowed named ARSP_EXT_IN. Remov- 
ing FRAME_COUNTER from the data flow ARSP_EXT_IN reduces the data flow 
to a single data element AR_COUNTER. So, the data flowed named 
ARSP_EXT_IN has been removed from the data dictionary and replaced in 
DFD 1 with the data flow AR_COUNTER . It is not clear why this item is 
listed as a deficiency of the design as the most recently released GCS 
Software Specification, version 2. 3-3. 3 clearly identifies the data 
element FRAME_COUNTER as an input to ARSP. 

t 

2) Range checking for the data element AR_ALTITUDE has been added where 
necessary . 

q 

3) The FORTRAN notation for the constant value 3x10 has been replaced 
with the notation "SxlO^O". 

ASP 

1) A check for a negative value has been added before performing the 
square root operation. It is not clear why the absence of the check 
is a deficiency of the design. 

W< ' / , 

2) Range checking for the data element A_ACCELERATION has been add^d as 
appropriate . 

TDLRSP 

1) A reference to the number of beams to be processed has been added to 
the "do loop" specifications. 

2) The "extra branches" have been removed from the radar beam state 
processing . 

3) Processing of the off-diagonal elements of K_MATRIX has been removed. 

4) The formula for computing "pbvY" has been corrected in both the de- 
scription of processing the beam velocities and in the expression of 


" Yes AR#(s) 
X No 

Do not know 


7. Was the action related to another action(s)? 


E-92 







Action Report Continuation 

page 2 of 2 

a. Report #: 

15.1 

b. Notes/Explanation (Please reference appropriate section number): 

the algorithm. The correct formula is: pbvY = (b(l)-b(2)- 
b ( 3 ) +b ( 4 ) )/4 . 

TSP 

1) The formula representing the lower parabolic function has been cor- 
rected by rewriting the formula such that it is now consistent with 
it's description. The correct formula is: lower-parabolic- temp- 

f unction= - (x- (M3+( ( (T4-T3)/(M4-M3) )/2) ) )~2 + (T3+ ( ( (T4 -T3 )/(M4 - 
M3) )/2"2) . 

2) In the derivation of the formula representing the upper parabolic 
function, the general equation of a parabola has been corrected by 

j rewriting the equation. The correct equation is: y = l/(4*p) * (x- 

I h)~2 + k. 
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GCS Problem Report 


2. Planet: 


3. Discovery Dale: 
July 13, 1994 


page I of 2_ 


4. Initiator & Role: 

lnspcctor/QuacIi anil Bcclicr 


5. Activity at Discovery: 



* Activity 

Development Phases II DR I CR I RC I RS I IRR I I CR I I CC | ICE I R 

Design ^ 

Code ■■ 

Unit Testing I I I 

Functional ^ 

Structural ^ 

Subframe Testing ^ 

Frame Testing ^ 

Top-Level Simulator ^ 

Integration Testing 


6. Description of Problem: 

The following are inaccuracics/deficiencies for tlic functional units in the control law processing 
subframe and the Communications Processing functional unit. 

RF.Cl.P, P-Spcc 3.4 

1 ) pages 3*4, deriving roll engine command: 

a) Setting UE_CMD for cases where TllliTA = 0 are incorrect. Specifically: 

III FT A = 0 and P > P2 and P <- P4 

THETA = 0 and P <- P2 and P > PI 

THETA < 0 and THETA >- -Til ETA 1 and P < -P2 

THETA < 0 and THETA >=■ -THETA 1 and P = -P2 

b) For the case where: 

THETA >= -THETA * G_I«)TA'HC)N < -P2, 
the value of UE_CMD docs not agree with the comment describing the values 

c) On page 4 - When checking the ranges in the "-THETA2" region - the following is incorrect. 

else if (THETA >= THETA2) then 


7. Artifact Identification: 

X Design Description 
__ Source Code 

Executable Object Code 


X. Test Case Identification: 


Support Documentation 
Other 


Configuration Item: 

Pluto Design Description P-Specs 1.8, 
3r«-, ZnJTanA-ar^ ^ j 


wammmnz*™ 


Person 
, Angellatta 
Quach 
Hayhurst 


Comments 




1 1. Total # of No Changes: 


10. Total # of Changes: 


12. Initiator Sinnntiire * Dntp 13. SOA Signature & Date - . 

^Original Signed by ^Original Signed by '7/3'Q-f < P y 

^Patrick Quach Kelly Hayhurst f 

* Activity: DR - Design Review; CR - Code Review; RC - Reading Coirc*-i«r- Kcailmg SpCcilication; TRR - Test Readiness 
Review; ICR - Test Completion Review; TCC - 'Test Case Creation; TCB - Test Case Execution; R - Regression; O - Other. 
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Problem Report Continuation 


page 2 _ of _2_ 


a. Report //: 16 


b. Notes/Explanation (Please reference appropriate section number): 
Section 6. Description of Problem (continued): 

AECLP, P-Spcc 3.2 


1 ) 


2) 


3) 


4) 


S) 


1 ) 

2 ) 


1 ) 

2 ) 

3) 

4) 


The if statements that implement table 5.1 do not specify the correct order of opcratioi) in two 
instances of the following: (according to fortran evaluation rules) 

If (PRAME_COUNTER - PRAME.ENGINES JGNITED * DELTA_ I <... 

Yaw_crror_limit equation (pg. 7) 

In the yaw_error_limit equation: "GtJ." is not tlic correct gain. 

Processing step enumeration (pg. 7-10) 

The enumeration of step "2C" on the middle of page 7 duplicates tlic previous numbering. I bis step 
should be "2D", Subsequent steps are also otr by 1 letter. 

The value of "c" (pg. 9) 

Typo in the value of "c" 

c= 2.718281828459045235360 

Concerning setting of AE_CMD from IN 1T.RNA1._C.MD (pg. 11) 

In the second branch or all 3 "ir" statements (as shown below), the inequality is incorrect 
"(INTERNAI._C.MD(i) < 1)" 


C.RC.P, P-Spcc 3.3 


Limit checking (pg. 1) 

Limits checking is not necessary for CI1UTE_RELEASED and AEJ1EMP. 
The variable assignment (pg. 1) for C.IIITI E_RELEASED is unclear. 


CP, P-Spec 1 .8 

The record and pointer notation is not clcaily explained 
Concerning the CRC. table: 

a) An algorithm description would aid verification. 

b) The design is not clear about the number or bits in tlic CRC 

The first subscript for K_MAT!RX (pg. 7) in the following is incorrect: 
DATA_PACKET.data.sp.k_matrix(3) = K_MATRIX(2,3,0) 

In the following: 

index = crc XOR ncxt_bytc 

the design has not staled that only the iow-ordcr byte ol crc is to be used. 
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page 1 of 2 


I . AR#: 

2. Planet: 


4. Respondent & Role: 

16.1 

Pluto 


Angellatta, R.K. Programmer 


5. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


Support Documentation 
Other 


Configuration Item: 

Pluto design description 
P-Specs 1.8, 2.2, 2.3, and 2.4 


6. Description of Action 
!/ RECLP 

la) A new case was added to the processing which determines the roll 
engine commands. The new case addresses the instance when THETA is 
equal to zero. The existing case which use to handle the condition 
when THETA is greater than or equal to zero has been altered to handle 
the condition when THETA is greater than zero. 

lb) The roll engine command for the case where THETA >= -THETA and 
G_ROTATION < -P2, is Maximum Counterclockwise. A comment indicated 
the correct command for this condition, however an inproper value was 
generated in the algorithm. The algorithm has been modified to assign 
the proper value. 

lc) The intended condition for evaluation is THETA >= -THETA2. The nega- 
tive sign was inadvertently missing from the expression. The expres- 
sion has been corrected by adding the negative sign to THETA2 . 

AECLP 

1) There are two instances of the expression: if ( FRAME_COUNTER - 

' FRAME_ENGINES_IGNITED * DELTA_T < ...) . The correct expression is: 

if ( (FRAME_COUNTER - FRAME_ENGINES_IGNITED ) * DELTA_T < ...), the sub- 
traction must occur before the multiply. These instances have been 
update with the correct expression. 

i 2) The formula for computing the yaw_error_limit incorrectly contains 

the data element "GQ" . The correct data element "GR" has been substi- 
tuded for "GQ" in the equation. 

. 3) The "steps" have been renumbered beginning with the second step 2C . 

4) The value of e has been modified to the value 2.718281828459045. 

5) The processing for computing the value of AE_CMD has three instances 
of the expression if ( INTERNAL_CMD( . ) < 1) then, the proper expression 
is if ( INTERNAL_CMD( . ) <= 1). These three instances have been updated 
with the correct expression. 


7. Was the action related to another action(s)7 


X 


Yes AR#(s) 
No 

Do not know 
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Action Report Continuation 


page 2 of 2 


16.1 


b. Notes/Explanation (Please reference appropriate section number): 

|/C!RCP 

1) CRCP has been totally written in accordance with the style of the 
other P-Specs. The limit checks for the data elements CHUTE_RELEASED 
and AE_TEMP have been removed from the processing. 

2) The computation of the data element CHUTE_RELEASED has been rewrit- 
ten and is now very explicit. 


The notation for the record and pointer syntax will be clearly de- 
scribed in the "overview" section of the design. A few comments have 
been added to this P-Spec to help c]0^rify the notation. 

A comment has been added to the CRC processing citing a reference 
which contains the algorithm for constructing the table* Also, sev- 
eral comments have been added with clearly indicate the number of 
bits being processed in the CRC. 

When building the data packet for the sensor processing subframe, 
the data element K_MATRIX (2,3,0) was inadvertently packed into the 


buffer twice. Actually, the second. 


K_MATRIX ( 2 ,3,0) 


should have referenced K_MATRIX ( 3 , 3 , Q}-r- — The second( occurancejhas 
been modified to the appropriate expression. 

Several comments have been includef|which explicitly indicate the 
number of bits, either lower 8 bits or all 16 bits, being operated on 
during the XOR operations. 
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GCS Problem Report 


page I of _2_ 


2. Planet: 

3. Discovery Date: 

4. Initiator & Role: 


Pluto 

July 13, 1994 

Inspcetor/Qtiach and Bccher 



5. Activity at Discovery: 


* Activit 


Development Phases 

I DR | CR 

RC | 

RS 

TRR 1 


R 

O 

Design 

IxJHH 


... 



Code 






Unit Testing 

| | 









Functional 










Structural 









Subframe Testing 









Frame Testing 









Top-Level Simulator 
Integration Testing 










fi. Description of Problem: 

The following are inaccuracies/dcficicncic.s in flic data flow diagrams and data dictionary. 

STRUCTURED ANALYSIS DIAGRAMS 

1 ) GCS Context Diagram 

PACKET docs not appear on any flow going out from the bubble GCS to the telemetry external 
sink. 

:) GCS DFD/CFD 

PACKF.T does not appear on flows coming from each of the three subframe bubbles and going 
off-page. 

3) Sensor Processing Subframe DFD/C.F1) 

PACKET docs not appear on a flow out from GCS_SIM_RENDE7.VOUS to off-page connector. 

4) Guidance Processing Subframe DFD/CFD 

PACKET does not appear on a flow out from GCS_SIM_RF.NDE7.VOUS to off-page connector. 


7. Artifact Identification: 
X Design Description 

Support Documentation 

Configuration Item: 

__ Source Code 

Other 

Pluto Design Description, Context 

Executable Object Code 


Diagram, DFD 0, 1,2, 3, and Data 



Dictionary 

8. Test Case Identification: 




9. History Log: 


WEBSSM 


Person 

Comments 

AM 

WPEESIflflM 


Angellatta 


n.t 



yjBfnSZEM c 

Quach 



\WiWfSEPi 

WBMEfFPM 

.Hayhurst 



1 


wmnmm 



| 10. Total ff of Changes: 1 1. Total ft of No Changes: 

| 12. Initiator Sinnnlnre Xr n.-ilp 
Original Signed by 

13. SOA Signature AiDate 

Original Signed by 7 (/ 


Patrick Quach Kelly Hayhurst ” * f 

* Activity: DR - Design Review; CR - Code Review; RC - Reading Code; RS -'Rending Specification; TRR - Test Readiness 


Review; TCR - Test Completion Review; TC.'C - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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Problem Report Continuation 


is 


page 2 of 2 , 

a. Report //: 17 


b. Notes/Explanation (Please reference appropriate section number): 

Section 6. Description of Problem (continued): 

S) Control Law Processing Subframe DFD/CFD 

a. PACKET does not appear on a How out from GCS_SIM_lU : .NDF.7.VOlJS to off-page ( 
connector. 

b. Flic data flow coming from GUIDANCF,_STATF. to AF.CLP docs not include 
INTF.RNAL_C.MD, but it is an input to AF.CLP. (Note: this is a result of Formal 
Modification 2. 3-3. 2) 


Data Dictionary 

t) Ordering of data clement is important for interoperability with GCS_SIM_RF.NDE7.VOUS but is 
not specified in the data store definitions. 

2) For data element, CL, the range does not correspond to its TcatnWork usage. 

/ 

3) Flic data element, END_GCS, is missing a description. 

4) The group flow, GP_GS_IN, includes 1 E_IN I EGRAL which is not an input to GP. 

1 / 

5) Typo in the following primitive data elements: 

CONTOUR_C.ROSSED 
G 1 
G2 
GVEI 

K_MATRIX 
TDLR_ANGLES 

TE_DROP 

/ 

6) j I he hexadecimal notation used in C.OMM_SYNC_PATTERN is only described in the P-5 


DESCRIPTION field 
UNITS field 
UNITS Held 
UNITS field 
ACCURACY field 
DESCRIPTION Held 
RANGE field 
DESCRIPTION field 


should be "...velocity-altitude..." 
should be "(mctcrs/scc A 2)/(dcgrcc_C)" 
should be "(metcrs/scc A 2)/dcgree_C A 2" 
should be "/scc A 2" 

Spec, has "N/A”. 

"y" should be "gamma" 

PI/2 should be excluded 
format error 
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GCS Action Report 


page 1 of 2 


1 . AR#: 

2. Planet: 


4. Respondent & Role: 

17.1 

Pluto 


Angellatta, R.K. Programmer 


5. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


Support Documentation 
Other 


Configuration Item: 

Pluto Design Description 


6. Description of Action 
Diagrams 

. i) 


J 


1 2) 
' 3) 
4) 
|/£) 


A data flow labeled PACKET has been added to DFD Context-Diagram 
depicting the data element PACKET flowing between the GCS process and 
and external device named COMMUNICATOR. A data flow labled PACKET has 
also been added to^DFD 0, DFD 1, DFD 2, and DFD 3. The output lists 
of P-Specs 1.1,/1.2^ and( 1 . 3) wh)ere all modified to include the data 
element PACKET. — ^ J .. ( 

See item 1 . 

See item 1 . 

See item 1 . 




a) See item 1. b) The data flow AECLP_GS_IN was modified to include 
the data element INTERNAL_CMD . P-Spec 3.2 was modified to include the 
data element INTERNAL_CMD as an input. 

Data Dictionary 

1) The SA tool does not provide a method for specifying the ordering of 
elements within a data store. However, a comment was entered in each 
of the data stores: EXTERNAL, GUIDANCE_STATE , RUN_PARAMETERS , and SEN- 
SOR_OUTPUT indicating the proper ordering of the data elements . 

/' 

The range of the data element CL has been modified from the incorrect 
specification ["0" | "1"] to the correct specification ["1" | "2"]. 

yi) The control flow END_GCS will be removed from the design during the 
processing of PR #18. 

4) The data element TE_INTEGRAL has been removed from the data flow 
"'GP_GS_IN. The data element TE_INTEGRAL has been removed from the in- 
put list of P-Spec 2.2. 

5) The phrase " velocity_altitude" has been changed to "velocity- 
altitude" in the data dictionary entry for CONTOUR_CROSSED . The 
phrase "meters/sec~2" has been changed to " (meters/sec , '2)/(degree_C) " 


Yes AR^(s) 
X No 

Do not know 


7. Was the action related to another action(s)? 


E-100 







Action Report Continuation 


page 2 


of 2 


a. Report #: 
17.1 


b. Notes/Explanation (Please reference appropriate section number): 

in the data dictionary entry for Gl. The phrase "(me- 
ter s/sec'' 2 ) /( degree\*C~2 " has been changed to "(me- 
ters/sec'' 2) /degree-CT 2" in the data dictionary entry for G2 . The 
phrase "/second**2" has been changed to "/sec / '2)" in the data dic- 
tionary entry for GVEI . The phrase "TBD" has been changed to "N/A " 
in the data dictionary entry for K_MATRIX. The phrase "y" has been 
changed to "gamma" in the data dictionary entry for TDLRlANGLES . The 
phrase "[0, PI/2]" has been changed to "[0, PI/2)" in the data dic- 
tionary entry for TDLR_ANGLES . A carriage return was added to the 
"description" field of the data dictionary entry TE_DROP . ^\h comment 
has been added to the data dictionary entry COMM_SYNC_P ASTERN indi- 
cating the use of hexadecimal notation. 
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GCS Problem Report 


page I of _2_ 


' 1. PR tf: 

2. Planet: 

3. Discovery Date: 

18 

Pluto 

July 13, 1994 


4. Initiator & Role: 

Inspcctor/Quach and Bccticr 


5. Activity at Discovery: 


* Activity 

I CR I RC I RS I TRR 1 TCR I I CC I TCE | R O 


Development Phases 11 DR 


Design 


Code 


Unit Testing 


Functional 


Structural 


Subframe Testing 


Frame Testing 


Top-Level Simulator 
Integration Testing 



fi. Description of Problem: 

The following are inaccuracics/dcficicncics in the guidance processing subframe. 

1 ) TP. .INTEGRAL is not an input to this process. 

2) In the text which describes the 5 step RK method for calculating attitude, velocity and altitude, 
clarification is needed on which history variable Is being used in the derivative calculation 

3) hi the implementation notes for the RK method, the incorrect variable. GP.ROTATION, is used for 
calculating GP.ATTITIIDE and GP.VELOCITY. 

4) In the setting of tbe GP.ROTATION matrix, the wrong history subscript is being used for the 
G.ROTATION elements. 


7. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


Support Documentation 

Other 


Configuration Item: 

Pluto Design Description, P-Spec 2.2 


8. Test Case Identification: 


9. History Loj 
Date To 

Date From 

Person 

Comments 

AM 





/8 1 





R/'J 

9H 

Quach 


HP- 

P)l<k 

qcj 

.Hayhurst 



— 1 _ 


-H — 





1 1 . Total ff of No Changes: 




12. Initiator Sionntiiri* Jb lint** 

'Original Signed by 

""^Patrick Quach n .. 

* Activity DR - Design Review; CR - Code Review; RC - Reading Code; RS - Reading Specification: TRR - Test Read, ness 
Rcvii'V i TCR Tcs, cLpIC,™ Review; TCC • To, Co. C,Wl« TCB - T« Coe Hvecutinn; R - Reg,e SS ,»„: O - 0,1, e,. 


13. SOA Signature. Date 

Original Signed by 
"Kelly Hayhurst 
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Problem Report Continuation 


page 2 of 2 _ 


a. Report 1i: 18 

b. Notes/Iixplanation (Please reference appropriate section number): 

Section 6. Description of Problem (continued): 

$) In each case there is no check for a negative argument before the square root is taken. 

f>) in several instances of divlde-by-zcro checking, there arc extra output from error mcssagcs'that can 
not be traced to the Requirements. The text in question is: 

"COMPUTATION OP OPTIMAL VF.LOOIIT" 

' 7) In reference to the following IF statement in page 8: 

if ((CONTOUll_ALTn'UDE == 0) .or. (index == 100)) then 

a) CONTOUR_ALTITUl)F is a vector but has no subscript. 

b) the variable index is undefined. 

8) T he overview states that "ENI)_C.CS would not be implemented". If that is the case, it should not be 
' shown Inside a P-Spcc.. 
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GCS Action Report 


page 1 of 2 


1. AR#: 

2. Planet: 

3. Date of Action: 

18.1 

Pluto 

Aur 1, 1994 


5. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


6. Description of Action 


Support Documentation 
Other 


4. Respondent & Role: 

Angellatta, R.K. Programmer 


Configuration Item: 

Pluto Design Description, 
P-Spec 2 . 2 


1) PR #17, the data dictionary section item #4, the data element 

\ ^ TE_INTEGRAL was removed from the input list of P-Spec 2 . 7 ,. 

2) The description of the 5 step RK method employed for computing the 
attitude, velocity, and altitude has been modified to include a more 
detailed description of the computation of derivatives. 

3) Here is a problem. The data element GP_ROTATION is not contained in 
the input list for the P-Spec 2.2 GP. Thus, the contents of 
GP_ROTATION not available for processing in P-Spec 2.2. However, 
Table 5 . 8 clearly states that the computations for the current values 
of GP_ATTITUDE and GP_VEU0CITY depend upon the value of , GP_ROTATION . 

In order to avoid this discrepancy in the specification, the computa- 
tions of GP_ATTITUDE and GP_VELOCITY have been revised to refer to the 
data element G_ROTATION rather than GP_ROTATION. 

4) 7 When assigning values to the elements of GP_ROTATION, the design 

/ inadvertently refered to the first history of G_ROTATION when zero is 
v the correct history of G_ROTATION. The design has been modified to 
refer to the zero history of G_ROTATION when assigning values to the 
elements of GP_ROTATION. 

5) There are two instances where a check for a negative value has been 
added before performing a square root operation. It is not clear inA- 
either case why the absence of the check is a deficiency of the de- \ - 

Sign - I Jr 

'• 

6) .- There are three instances in which the extra output from a divide by •• 
/ zero exception message have been removed from the output. 


a), and b) In reference to the phrase "if ( (CONTOUR_ALTITUDE == 0) 
.or. (index == 100) then" the correct phrase is "if (CON- 
TOUR_ALTITUDE( i ) == 0) .or. i == 100)." The design has been modified 
to include the correct phrase. , 4 

The signal END_GCS has been removedyrrom the design. The data ele- 
ment GP_PHASE is now used as a signal for controlling the overall acti- 
vation of the processing comprising GCS. DFD 0, ni>FD 2, PAT 0-sl and 


sing GC 
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GCS Problem Report 



2. Planet: 


3. Discovery Date: 
August 1 1, 1994 


page I of 1. 


4. Initiator & Role: 

Inspcctor/Quacli and Bcclicr 


5. Activity at Discovery: 


* Activity 

Development^^ DR I CR I RC I RS I TRR 1 TCR | TCC I ICE I R 

Design ^ 

code BU T I 

Unit Testing , 

Functional ^ 

Structural ^ 

Subframe Testing 

Frame Testing ^ 

Top-I.evel Simulator 
Integration Testing 


6. Description of Problem: 

1 ) The Design Introduction has format and inconsistencies which hinder readability 
and comprehension. 

2) The Design Description contains inconsistent notations and duplicate information. 



7. Artifact Identification: 

X Design Description 
___ Source Code 

Fxecutable Object Code 


8. Test Case Identification: 


Support Documentation 

Other 


Configuration Item: 

Pluto Design Introduction 
Pluto Design Description 



WBEIWKZFPKEM 




10. Total # of Changes: _ 


12. Initiator Sinnatnro & Dale 


1 1 . Total # of No Changes: 


I 13. SOA Signature & Date 


Original Signed by ft- ZQ c /*f | Original Signed by 8A3 (o{Q4 

Patrick Quach Kelly Hayhurst * ' ' 

* Activity: DK - Design Review; CR - Code Review; RC - Reading Code; RS - Reading Dpccmcaiinn; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCF - Test Case Execution; R - Regression; O - Other. 
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GCS Action Report 


page 1 of 2 


1. AR#: 

2. Planet: 

3. Date of Action: 

4. Respondent & Role: 

19.1 

Pluto 

Aug 11, 1994 

Angellatta, R.K. Programmer 

1 


5. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


Suppo 1 Documentation 
Other 


Configuration Item: 

Pluto Design Introduction 
Pluto Design Description 


6. Description of Action 

1) Modifications to the Design Introduction. 

The Design introduction has been entirely rewritten to cpmply with the 
design documentation standards as specified in the Software Develop- 
ment Standards . 

2) Modifications to the Teamwork Model. 

A) The name of the implementation has been changed from "GCS" to 
"PLUTO." This change affected the name of process 0 in the context 
diagram and DFD 0, and the name of PAT 0-sl was affected as well. 

B) The body of P-Specs 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 2.2, 3.2, 

3.3, and 3.4 have all been modified to reflect the algorithm descrip- 
tion syntax as described in the Design Introduction. For the most 
part these changes involved altering the comment delimiters (from "/* 
*/" to "(* *)"), altering the assignment operator (from "=" to ":="), 
altering the logical operators (from "==" to "=", from ".AND." to 
"AND", from ".OR." to "OR", and from ".NOT." to NOT), and altering the 
array notation (from "()" to "[]"). 

C) Notes on the derivation of the algorithms where removed from the 
body of P-Specs 1.2 and 1.7 and inserted into the Design Introduction 
along with the algorithm notes of the other P-Specs. 

3) While reviewing the Pluto design for the changes made against this 
problem report, the verification analyst discovered that the formula 
specifying the "upper parabolic region" in P-Spec 1.7 TSP is incor- 
rect. P-Spec 1.7 and the design introduction have been updated to 
reflect the proper equation. The correct equation is: 
upper-parabolic-equation = 

(x- (M4- ( ( (T4-T3)/(M4-M3) )/2) ) )*2+(T4- ( ( (T4-T3)/(M4-M3) )/2~2) 

4) While reviewing the Pluto design for the changes made against this 
problem report, the verification analyst discovered that in P-Spec 2.2 
GP, the error message reporting the data elements GP_ALTITUDE [ 0 ] and 
GP_VELOCITY [ 1 i 0] "out of range" are incorrect. The incorrect error 
message listing the GP process as "ASP." This problem has been cor- 
rected by identifying the GP process as "GP." 


Yes AR#(s) 
X No 

Do not know 


7. Was the action related to another action(s)7 
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Action Report Continuation 

page 2 of 2 

a. Report #: 

19.1 

b. Notes/Explanation (Please reference appropriate section number): 

5) While reviewing the Pluto design for the changes made against this 
problem report, the verification analyst discovered that in P-Spec 
2.2 GP, a range check was not performed on the data element VELOC- 
ITY_ERROR as required. A range check was added as necessary to P- 
Spec 2 . 2 GP for the data element VELOCITY_ERROR . 
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GCS Problem Report 



2. Planet: 


3. Discovery Date: 

September 15, 1994 


4. Initiator & Role: 

Dcsigncr/Angcllalta 


5. Activity at Discovery: 


Development Phases 

Design 

Code 

Unit Testing 

Functional 

Structural 

Subframe Testing 

Frame Testing 

Top-Level Simulator 
Integration Testing 


* Activity 

RS I TRR 1 TCR I TCC 1 ICE 



6. Description of Problem: 

The following updates are needed In the Pluto design to maintain compliance with the 
GCS Specification as updated by Formal Modification #2.3-4. 

1) The base type of the data clement "AE_TEMP" has been changed to Integer instead 
of Logical. 

2) The data clement ”CMUTE_RELEASED" has been reassign to the EXTERNAL data 
store and removed from the GUIDANCE_STATE data store. 


7. Artifact Identification: 

X Design Description 
_ Source Code 

Executable Object Code 

Support Documentation 

Other 

Configuration Hem: 

Pluto Design Description 

8. Test Case Identification: 



^minwm mtmmm 


10. Total# of Changes: 11. Total# of No Changes: 

12. Initiator Signature & Date 13. SOA Signature A Date 

■ Original Signed by | (?. V Original Signed by 

Rob Angellatta Kelly Hayhurst 

♦ Acuvity: uk - ucsign kcvicw; CR - Code Review; RC - Reading Code; K5 - Reading spccilication; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 


E-109 







2. Planet: 
Plut 


GCS Action Report 

pace I nf 2 


4. Respondent & Role: 

Angellatta, R.K. Programmer 



5. Artifact Identification: 

1 - l 1 

Configuration hem: 

X Design Description 
Source Code 

Support Documentation 
Other 

Pluto Design Description 

Executable Object Code 




6. Description of Action 

Formal Modification 2. 3-4.1 

No modifications to the Pluto design are necessary. ' 

Formal Modification 2. 3-4. 2 

No modifications to the Pluto design are necessary. 

Formal Modification 2. 3-4. 3 

a) The DDE AE_TEMP has been modified, the "data type" field has been 
changed from "Logical-1" to "Integer-2". 

b) P-Spec 1.8 CP has been modified as follows. The data type Integer- 
2 is two bytes in size, one byte larger then the data type Logical-1. 
This difference in the size of the data type for AE_TEMP makes it 
necessary to increase the length of the data packet for the third 
subframe. The data type of field AE_TEMP in the record structure 
"clp data_t, " which represents the data packet for the third subframe, 
has been changed from "byte" to "word" . The comments regarding the 
length of the data packet have been changed from "44 bytes" to "45 
bytes". The "length" argument of the call to function CRC16 for the 
third subframe has been changed from "44" to "45". 

Formal Modification 2. 3-4. 4 ^ 

The data element CHUTE_RELEASED Has been removed from the DDE GUID- 
AttCE_STATE and the data fiows named CP_GS_IN, GP_GS_IN, and AE- 
CLP_GS_IN. ' In DFD 2, the input data flow labeled FRAME_COUNTER con- 
necting the data store EXTERNAL to bubble 3.2 has been renamed 
GP_EX_IN. GP_EX_IN contains the data elements CHUTE_RELEASED and 
FRAME_COUNTER . In DFD 3, the input data flow labeled FRAME_COUNTER 
connecting the data store EXTERNAL to bubble 3.2 has been renamed AE- 
CLP IN. AECLP_EX_IN contains the data elements CHUTE_RELEASED and 
FRAME COUNTER. Also, the data element CHUTE_RELEASED was removed from 
the data flow named CRCP_GS_IN. This action reduced the data flow to a 
single data element so the label CRCP_GS_IN was removed from the data 
flow and replaced with the single element name AE_TEMP . The input 
data flow labeled CHUTE_RELEASED connecting the data store to bubble 
3.3 was removed and an input data flow labeled CHUTE_RELEASED connect- 
ing data store EXTERNAL to bubble 3.3 was created. Similiarly, the 
output data flow labled CHUTE_RELEASED connecting bubble 3.3 with data 


7. Was the action related to another action(s)? 


^es AR#(s) 
t/No 

Do not know 
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Action Report Continuation 


pnet 2 


20.1 

Notes/Exp] anation (Flease reference appropriate section number): 

store GUIDANCE state was. removed and an output flow labeled 
CHUTE RELEASED connecting bubble 3.3 with data store EXTERNAL was 
created . 


Formal Modification 2. 3-4. 5 

No modifications to the Pluto design are necessary. 


E- 



GCS Problem Report 


2. Planet: 

3. Discovery Date: 

Pluto 

Nov. 16, 1994 


page I of 2_ 


4. Initiator & Role: 

Inspcclor/Quach and Bcclicr 


5. Activity at Discovery: 


* Activity 

Development Phases || DR I CR | RC I RS I TRR I TCR | ICC | ICE 

Design 

code bhhhhm 

Unit Testing 

Functional 

Structural ^ 

Subframe Testing ^ 

Frame Testing ^ 

Top-Level 
Integration Testing 


II 


6. Description of Problem: 

'flic following are inaccuracies/dcficiencics in the data How diagrams, data dictionary, and design 
introduction. 

1 ) CiCS DFD-0 docs not balance. 

2) GCS PAT 0-S I 

a) The comment above the table indicating what GIM’HASP. is initialized to is inaccurate. 

b) The table is missing the label for activation sequence where GP_PIIASH <> "5" 

ICS Data Dictionary Inaccuraclcs/deflciencics 

3) The clement CllUTF_RF.LnA.SHD has an incorrect entry in its DATA STORK field. 

4) The following data elements in the data dictionary have "data condition" entered in their 
ATTRIBUTE field but are used only as "data" Hows. 

AE_swrrcn ah_thmp 

CONTOUR_CROSSHD RK_SWITCI I 

TD SENSED TD1.R_.ST ATE 


7. Artifact Identification: 

X Design Description 

Source Code 

Executable Object Code 

Support Documentation 

Other 

Configuration Item: 

Pluto Design Description 

K. Test Case Identification: 



mnjnmmuEnmm 



1 0. Total ft of Changes: JO. 1 1 . Total #/ of No Changes: 


1 2. Initiator/Siunatun* & Date 13. SOA Siunatuic A Date 

Original Signed by jf - 2SL- ~ °l ^ Original Signed by 

Patrick Quach Kelly Hayhurst ’ ' 

* Activity: DK - Design Review; CR - Code Review; RC - Reading Code; KS - Refilling Rpccilication; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 


I \jSrJ 

nn; TRR - Te 
Regression; 
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Problem Report Continuation 


page 2 of 2 

a. Report ft: 21 

h. Notes/Explanation (Please reference appropriate section number): 

5) The element C()MM_SYNC_PATTP.RN has a typo in its RANCH 7 . field 
Design Introduction Inaccuraclcs/dcficlcncics 

6) It would he helpful if the pages arc numbered in the introduction. 

i 

7) The paragraph in section 2.2 justifying deficiencies in DPI) should he removed. It is no longer 
needed if DPD-0 is to be changed so that it balances. 

8) Typo itt section 1 .3 

"...previous chosen to signify..." 

9) Typo in section 2.3 

"... oincidc ..." 

10) Typo in section 2.3. In the description for AP.C7.P. TP._I,IMIT calculation, symbol for 
acceleration (X double dot) lias inconsistent case. Its capitalized in the first 2 instances and 
lower case in the last instance. 
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GCS Action Report 


iacc 1 of 1 



6. Description of Action 


The following actions were taken to correct inaccuracies^cficicncics in the data flow diagrams, data 
dictionary, and design introduction pertaining to problem report #21 . 

/)) GCSDFD-0 

Data flows and Stores were added to GCS DFD-0 to make it balance. 

4) GCS PAT 0-S 1 

a) The comment above the table was removed. 

b) The label "Other" was added to the table for cases when GP_PHASE <> "5" 

3) The element CHUTE_RELEASED entry in its DATA STORE field was changed to EXTERNAL. 

4) The following data elements in the data dictionary were corrected to have "data" in their ATTRIBUTE 
field: 

AE_S WITCHED AEJIEMP 

CONTOUR_CROSSED RE.SWITCII 

TD.SENSED TDLR_STATE 

5) The element COMM_SYNC_PATTERN entry in its RANGE field was changed to hexadecimal (the 
more common spelling). 

6) The Design Introduction's page numbers were raised to the printable region of the paper. 

7) Two paragraphs were removed in section 2.2 since DFD-0 now balances. 

8) The typo in section 1 .3 "...previous chosen..." was changed to "...previously chosen..." 

9) The typo "...oincide..." could not be found in section 2.3. 

■ 10) In the description of AECLP, TE_LIMIT calculation in section 2.3 one instance of (X double dot) was 
altered from normal to symbol to give it consistent text weight. 


7. Was the action related to another action(s)? Yes AR#(s) 

X No 

1 don't know 
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GCS Problem Report 


l.PR#: 

22 

2. Planet: 

Pluto 

3. Discovery Date: 
Nov. 16, 1994 

4. Initiator & Role: 

Inspcctor/Quach and Bcchcr 

5. Activity at Discovery: 

* Activi 

Development Phases H DR 1 CR 1 RC 1 RS I TRR 

T TCR 1 TCC iTCEl R I O I 


Design 


Code 


Unit Testing 


Functional 


Structural 


Subframe Testing 


Frame Testing 


Top-Level Simulator 
Integration Testing 



6. Description of Problem: 

The following are inaccuracies/dcficicncics in the functional unit P-Spccs in the PLUTO design. 

1) The following P-Specs contain "return" as the P-Spcc terminator. This may cause confusion 
among readers and should be removed: 

CRCP 
AECLP 
ASP 
ARSP 
GSP 
RECLP 
TDLRSP 
TDSP 
TSP 
GP 


7. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


Support Documentation 

Other 


Configuration Item: 

Pluto Design Description 


8. Test Case Identification: 


9. History Lof 
Dale To 

Dale From 

Person 

Comments 

ARtf 

ill va Li J 

iiyjsfffgi 

Morris 


mxmm i 

|VIIIggM 


Quach 



10. Total # of 

Changes: K < 

11. 

Total tt of No Changes: 



Original Signed by 
"Patrick Quach 




> Original Signed by 
"Kelly Hayhurst 


JL UU1V1V V^WMVW • , 

* Activity: DR - Design Review; LK - Lode Review; RC - Reading Code; RS - Redding Specification; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression: O - Other. 
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Problem Report Continuation 


a. Report ft: 22 

b. Notcs/Explanation (Please reference appropriate section number): 

Inaccuracies/deficiencies specific to ASP 

2) ltJias been determined in the code review dial the equation for computing the standard 
deviation found in the most recent version of the Specification should be used. As a 
consequence, the comment on page 4 near the bottom addressing the digital representation of 
real numbers can be removed. 

3) Also as a consequence, the description for computing the standard deviation should be 
updated. 

Inaccuracies/deficiencies specific to CP 

4) At the bottom of page 5 where subframcj is defined: 

"type subframcj = (subframcj. gp_data_t, clp_data_t) M 
The"subframc_t” ,on the right hand side or the assignment, is incorrect. 

5) At the top of page 8, in each of the assignment statements for GP_ROTAT10N and 
GP_VELOCITY, there is no subscript on the left hand side. 

6) At the bottom of page 9, where the looping starts for computing the CRC, the statement: 

"do for each byte in the message nexl_bytc", docs not specify which index to start with, 
i.c. 1 to 255 or vice versa. 

7) In the middle of page 7, the assignment statements for the following variables use the wrong 
closing index marker: 

TDLR_STATUS12] 

TDLR_STATUS[3] 

TS_STATUS[2] 

8) Typo on page 2:: In comments, "consist of" should be "consists of 

9) Typo on page 3: Comment which gives total no or bytes for sensor processing, " 1 27" should be 
"129" 

10) Typo on page 4: In comments, "returns and integer" should be "returns an integer 

Inaccuracies/deficlencles specific to GP 

11) Typo on page 9: 

"Exapolation" should be ""Extrapolation" in two places 
"Exapolate" should be "Extrapolate" 

12) Typo on page 10: "range check the current altitude" should be "range check the 

| VELOCITYJERROR" 


page 2 of _i_ 
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Problem Report Continuation 


page JL of JL 


a. Report #: 22 

b. Notcs/Explanation (Please reference appropriate section number): 

13) Typo on page 11 

"GP.ALTITUDEIOI =<" should be "GP_ALTITUDE[0] <=" for consistency 

14) On the top of Page 6: In each of the equations for att_k2, vcl_k2, alt_k2, att_k3, vcl_k3, and 
alt_k3, the right parenthesis preceding the term 72" is not in the correct place., and thus 

the attitude, velocity, and altitude arguments Tor the derivative routines arc not correct. 

15) An unnecessary range check for altitude follows llic ' END P_SPEC marker. 

16) In the description for computing the vehicle velocity, the description for pv, qv, rv arc in the 
middle of the velocity derivative computation. This is potential confusing. 

Inaccuracies/deficiencies specific to TDLRSP 

1 7) Typo on the bottom of page 7, the statement: 

"where cos represents the cosine function" 

appears to be a comment but has not been delineated as such. 

Inaccuracies/deficiencies specific to ARSP 

1 8) Typo at the bottom or page 2: "rccicvcd" should be "received" 

Inaccuracies/deficiencies specific to TDSP 

19) Typo in page 1: "hexidccimal" should be "hexadecimal" 


E-117 


GCS Action Report 
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I. AR #: 


22 . | 



2. Planet: 

3. Date of Action: 

4. Respondent & Role: 

i 

Pluto 

Nov. 29, 1994 

Reader/Morris 


5. Artifact Identification: 

X Design Description 
Source Code 
Executable Object Code 


jfr support Documentation 
Other 


Configuration Item: 


6. Description of Action 

The following actions were taken to correct inaccuracies and deficiencies in the P-Specs pertaining to problem 
report #22. 

1) In the following P-Specs "return" was removed: 

CRCP AECLP ASP 

ARSP GSP RECLP 

TDLRSP TDSP TSP 

GP 

2) In P-Spec ASP, the comment before computing the standard deviation addressing digital representation j 
of real numbers was removed. 

3) In P-Spec ASP, The description for computing the standard deviation was updated to match the spec. 

EXTRA In P-Spec ASP, the comment and description for checking for negative values following the 
computation for the standard deviation was removed since it was no longer needed. 

4) In P-Spec CP, the assignment "subframe_t" on page 5 was altered to "sp_data_t". 

5) In P-Spec CP, subscripts were added to each assignment statement for GP_ROTATION and 
GP_VELOCITY on page 8. 

6) In P-Spec CP, "do for each byte in the message next_byte" on page 9 was altered to read, "do 
next_byte :=■ 1 to bytecount" to remove confusion on the value of next_byte. 

7) In P-Spec CP, the index markers were changed from ")" to "]" for TDLR_S TAT US and TS_STA1 US. 

8) In P-Spec CP, in the comments on page 2 "consist of" was change to "consists of". 

9) In P-Spec CP, in the comments on page 3 total number of bytes was altered from "127" to "129". 

10) In P-Spec CP, in the comments on page 4 "returns and integer" was changed to "returns an integer". 

11) In P-Spec GP, in various comments on page 9, "Exapolation" and "Exapolate" were changed to 
"Extrapolation" and "Extrapolate" respectively. 

12) In P-Spec GP, in the comments on page 10 "range check the current altitude" was changes to read, 
"range check the VELOCITY_ERROR" 

13) In P-Spec GP, on page 1 1 "GP_ALTITUDE[0j °<" was change to "GP_ALT1TIDE <°" 


7. Was the action related to another action(s)? 


Yes AR#(s) 

X No 

I don't know 
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GCS Action Report Continuation 


page 2 of 2 


2. Planet: 3. Date of Action: 4. Respondent & Role: 

Pluto Nov. 29, 1994 Reader/Morris 


6. Description of Action 

14) In P-Spec GP, on page 6 the closing parenthesis for the equations for att_k2, vel_k2, alt_k2, att_k3, 
vel_k3, alt_k3 was moved to precede the term " 12 ". 

15) In P-Spec GP, the range check for altitude following "End P_SPEC" was removed. 

16) In P-Spec GP, the description for pv, qv, and rv was moved into the comments above' the description 

for computing vehicle velocity. 

17) In P-Spec TDLRSP, on page 7 "where cos represents the cosine function" was delineated as a 
comment. 

18) In P-Spec ARSP, in the comments on page 2, "recieved" was changed to "received". 

19) In P-Spec TDSP, in the comments on page 1 , "hexidecimal" was changed to "hexadecimal". 


7. Was the action related to another action(s)? 


Yes AR#(s) 

X No 

I don't know 







GCS Problem Report 


I. PR #: 



2. Planet: 

3. Discovery Date: 

23 

Pluto 

Nov. 16, 1994 


page 1 of 4_ 


4. Initiator A Role: 

Inspcctor/Qunch and Occlicr 


5. Activity at Discovery: 



Frame Testing 
Top-Level Simulator 
Integration Testing 


6. Description of Problem: 

The following arc innccuracics/dcficicncics in the riuto source code. 

1) • For traceability and document accounting purposes, it would he useful to indicate lire P-Spcc. 

identification in tbc source code files wbicli map to a design artifact. 

2) Constants used in tbc code, in tbc following cases, should have the appropriate precision ns 


required for the particular usage: 
Subroutine Name 

Lines 

Constant 

•{AECLP.FOR 

978 

"0.5" 

ASP.FOR 

818,837 

"3.0" 

ARSP.FOR 

746 

"3E0S” 

or .FOR 

995, 1(K)7, 1017 

"6.0" 


993, KX)6,I017 

"2.0" 


1086 

"t 000.0" 

TDt.RSP.FOR 

925.935,948,959... 

"2.0" 

n/TSP.FOR 

738,749 

"0.15” 

I.OWER_PARABOLIC_FUNCIION 

178 

"2.0" 

DPPER_PARADOLlC_FUNCriON 

178 

”2.0" 


7. Artifact Identification: 

Design Description 

X Source Code 

Executable Object Code 


Support Documentation 

Other 


Configutation Item: 

Pluto Code 


R. Test Case Identification: 


9. History I.oe 
IlatR Tn 



Comments ( ( 

ARH 


MFWHEM 



■ 

IwcwnizvM 

mnmmm 



1 

ISmjmfvS 

UZ ilT 

iHfivhiirRt \ 

OrA* ,.*?<> ■Vr>v_oK.'r \<v •fMa.c.k. 


1 U. 



Ac h,L ' — 1 



10. Total If of Changes: 33. 


12. 1 initiator Signature A Date 

Original Signed by 
Patrick Quach 


/Z-S ' L l 1 1 




13. SOA Signature A Drfte 

Original Signed by 
Kelly Hayhurst 


\X 


tek 


♦ Acll.Hr I>1< - ircsign Review; CR • Colic Review; RC - Rending Code; RS - Kenning spcclllcalion; TRR - Icsl Rcniliiicss 
Review; TCR ■ Test Completion Review; TCC - Test C«tc Creation: ICR - Tcttl Cove R.eeution: R ■ Regrcsaon: O - Olher. 
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Problem Report Continuation 


page 2 of 4 


a. Report tt: 23 


h. Notcs/Explanallon (Please reference appropriate section number): 
3) 


4) 

5) 

6 ) 

7) 

R) 

9) 

'lO) 


M) 

12 ) 

./ 


13 ) 

i‘ i) 


y 

is) 

/ 

ifi> 


17) 


1R) 


CONS T ANT. FOR: lire upper and lower bounds of all teal constants need to lie 
appropriately entered. 

CONST ANT.FOR: The constants for AF, TEMP have incotrect types, lltcy should be 
INTEGERS 

FXTFRNAF.FOR: Under "structure /clp_data_t/", the data type Tor aejcinp is 
incorrect. 

FL.UrO.FOR: The third subbaiuc is not executed when GP_PHASE - 5. According to the 
Specification, the third subframe should be executed before exiting the loop. 

PI.irrO.FOR: A GOTO statement is used to exit the loop, this should Ire avoided iT 
possible. 

A F.CI. P. FOR: A dividc-by- 7 .cro check is required Tor the variable OMEGA, at lute R95-R97 

CP.FOR: In line 37 oT the CRC16 subroutine, the hexadecimal constant given Tor the CRC- 
16 generator polynomial is not correct. It has an extra "1" before the "A". 

CP.FOR: In die CRC16 subroutine, the section "Returns...” in the subroutine header states 
that CRCI6 Is "the CRC-16" or the specified message." The "CRC-16 Is a bit ambiguous, ns 
it docs not explicitly slate It is the checksum or error code. 

CP.FOR: Hie assignment or the sequence field directly from the MOO intrinsic function is 
erroneous, the MOD function returns a integer quantity but its assigned to a logical. 

ARSP.FOR: There is a typo in the comment for step 3C) 

"...mostly recently..." 

OP.POR: In line 909, the first argument , namely "att_k1". is incorrect. 

GP.FOR: In lines 921 & 922, 925 ft 926. 929. 939 ft 940. 943 ft 944. and 947 the 
subroutines avg_alt and avg_vcl arc performing an incorrect function, and thus the 
second argument for each derivative call is incorrect. 

GP.FOR: hi line 970, the last argument Tor dcrivjvcl, namely I ", is not correct. 

GP.IHR: Fines 1095, 1 1 14. 1 132. 1156. 1203. 1224, and 1256 use unconditional GOTO 
statements deviating from the design 

Gr.FOR: In line 1 1 78, the relational operator, namely ".OF..", is a typo. .Should be 
.FE. according to the design 

GP.FOR: In die DERtV_AfT subroutine lines 72-74, it was intended that the 
vatiablcs pv, qv, and rv will yield lire apptoprialc values of G_ROTATION. The 
EQUIVA1 ENCE statements do not accomplish what was intended because Fortran arrays 
me column major, and therefore, lines 78 through 88 will yield incorrect results. 
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Problem Report Continuation 


page _2_ of _4_ 

a. Report tt: 23 

b. Notcs/F.xplanation (Please rcrcrcncc appropriate section number): 


19) OP.FOR: In the DP.RIV_VEL subroutine tines 297-299. it was intended tlrnt lire 
variables pv, qv, and rv will yield the appropriate values or CI_ROTATION. I lie 
EQUIVALENCE statements do not accomplish what was intended, and therefore, lines 309. 

I 316. AND 323 will yield incorrect results. 

20) OP. FOR: In the DERIVJVEI. subroutine, the index for "lctnp(l)" is incorrect for the 
following statements: 

tcmp(l) = TDl.R_VELOC!TY(2,index) - vel(2) 
tcmp( I ) = TDLR_VELOCITY(3, index) - vcl(3) 

21) Or.POR: The subroutines A VO_AT! and A VG_VEl. arc performing an unnecessary 
function. 

22) OP.FOR: In the MULT_AIT subroutine, the second index, of the array element to be 
multiplied with the "factor", is incorrect for the following elements 

ntt( 1 .2) 
alt( 1 .3) 

att(2,2) 

att(2,3) 

att(3.2) 

atl(3,3) 

/ 

23) GSP.FOR: lire local variable "counter" is typed as a "rcaOR" when it should lx* an 
”intcgcr*2" 

TDI.RSP.FOR: In lines 906-909 the computed GOTO statement has no defardt ease to 
handle eases where the computed expression is other than I to 15 

TDI.RSP.FOR: lire brattch between lines 957-963 is missing a control statement and w ill 
incorrectly fall through. 

TSr.FOR: There is an inconsistency at line 718 in argument types being passed into the 
7.P.RO. CHECK subroutine. The first argument being passed in, "M2-M1" is art integer 
begirt passed into a real nrgumctrl. 

TSP.FOR: In lhel.OWER._PARAnOI.IC nJCNHON. In litre IRI. the addition 
operator in the term ”...M3 + half .slope..." is incorrect. 

TSP.FOR: In the lJPPER_PARAnOLIC_FUCNTION. Inline IRI, both arithmetic 
operators immediately ptccediitg "Italf. slopc" (namely attd then " 1 ") arc 
incorrect. 

UTII.n Y.FOR: In the subroutines RANGE. CHECK, NEO.VAI.UE, CHECK, and 
ZERO_CIIECK. the FORMAT statement 30 is missing "x," Immediately before the "14". 

EXTERNAL.FOR: Heading: "Origirtial” should be "Original" 


24) 

J 

2-5) 

/ 

26) 

/ 

27) 

/ 

28) 

1/ 

29) 


•Vl) 
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Problem Report Continuation 


page 4 of _4 


a. Report ff: 23 

b. Nolcs/Explanation (Please tercrcncc appropriate section number): 

3 1 ) ARP-FOR: page 6 . comment on line 970: 

"convcrlion" should be "conversion" 

32) GP.H)R: page 9. lines 1125. I HI, and It <19: 

"cxapolat..." should he "cxtrapolal..." 

33 ) GP.FOR: For the computed GOTO statement at line 1 1 90. the default processing just falls through. 
This is not robust. 
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GCS Action Report 


page 1 of 2 


1 1. AR #: ” . 

2. Planet: 

3. Date of Action: 

4. Respondent & Role: 

23. 1 

Pluto 

Dec. 1, 1994 

Reader/Morris 


< .‘vArtifact identification: Vtp'' 

\ Design Description /$ty Support Documentation Configuration Item: 

Js Source Code Ollier 

Executable Object Code 


6. Description of Action 

The following actions were taken to correct inaccuracies.deficiencies in the Pluto code pertaining to problem 
report #23. 

1) The appropriate P-Spec identification was added to all source code files. 

2) Most constants used in the code are as precise as required. Excerpt from VAX Fortran Volume 2, pg. 
2-45 "The data type of the value produced by an operation on two arithmetic elements of different types is the 
data type of the highest-ranked element in the operation." However, two constants were altered, 

AECLP.FOR "0.5" to "0.5D0" and TSP.FOR "0.15" to "0.1 5D0" , to insure the value would not change from 
casting. 

3) In CONSTANT.FOR a "DO" was added to the end of real constants that did not end in a "0", to insure 
the value would not change if casted. 

4) In CONSTANT.FOR the types for AEJTEMP were changed to INTEGER*2. 

5) In EXTERNAL.FOR the data type of ae_temp was altered to integer*2. 

6&7) In PLUTO. FOR a DO WHILE loop was implemented to remove the unconditional GOTOs and insure 
all subframes were executed. 

8) In AECLP.FOR a check for zero was added to avoid a divide-by-zero. 

9) In CP.FOR the extra "1 " was removed from the comment on line 37. 

10) In CP.FOR the comment for CRC16 the description of crcl6 was changed to state it was a bit 

checksum. 

11) In CP.FOR, Added a temp variable and equivalence command to properly cast the byte. 

12) In ARSP.FOR the comment for step 3C was altered to read "...most recently..." 

13) In GP.FOR the First argument on line 909 was altered to "vel_kl " 

14) In GP.FOR the averaging subroutines were changed to perform the correctly divide the last parameter 
by 2 instead of averaging. 

15) In GP.FOR the last argument for deriv_vel on line 970 was changed to "0". 


7. Was the action related to another action(s)? Yes AR#(s) 

X No 

I don't know 
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GCS Action Report Continuation 


page 2 of 2 

~ArJ: 2. Planet: 3. Date of Action: 4. Respondent & Role: 

23.1 Pluto Dec. 1, 1994 Reader/Morris 

6. Description of Act on 

16) In GP.FOR on lines 1 095, 1 1 1 4, 1 1 32, 1 1 56, 1 203, 1 224, and 1 256 use an unconditional GOTO. The 
design states using a do loop and breaking the loop by changing the incrementing variable. This is not 
allowed in Fortran, but is allowed in other languages. The unconditional GOTOs serve the best translation of 
the design in Fortran. 

17) In GP.FOR on line 1 1 78, the relational operator was changed to .LE. 

18) In GP.FOR in the DERIV_ATT subroutine, the references to pv, qv, and rv were replaced with their 
equivlent G_ROTATION variable. 

19) In GP.FOR in the DERIVJVEL subroutine, the references to pv, qv, and rv were replaced with their 
equivlent G_ROTATION variable. 

20) In GP.FOR in the DERIVJVEL subroutine, the indexes to temp were properly incremented. 

21) In GP.FOR the averaging subroutines were changed to perform the correctly divide the last parameter 
by 2 instead of averaging. 

22) In GP.FOR in the MULT_VEL subroutine, the indexes to alt were properly incremented. 

23) In GSP.FOR the variable "counter" was typed to "integer*2" 

24) In TDLRSP.FOR in lines 906-909 was given a default case of 2000. 

25) In TDLRSP.FOR in lines 957-963 was given a control statement. 

26) In TSP.FOR at line 7 1 8 an extra variable was added to cast M 1 -M2 to a real before using it as an 
argument for ZERO_CHECK. 

27) In TSP.FOR in the LOWER_PARABOLIC FUNCTION the equation was matched to the design. 

28) In TSP.FOR in the UPPER_PARABOLIC FUNCTION the equation was matched to the design. 

29) In UTILITY.FOR, an "x" was applied before the "14" in the format statements to the subroutines 

RANGE_CHECK, NEG_VALUE_CHECK, and ZERO_CHECK. 

30) In all source code files in the heading "Originial" was altered to "Original" 

31 ) ASP.FOR has no line 970 or page 6, so there was nothing to change. 

32) In GP.FOR all incorrect forms of "extrapolate" were corrected. 

33) In GP.FOR the computed GOTO statement at line 1 190 was given a default. 

7. Was the action related to another action(s)? Yes AR#(s) 

X No 

I don't know 
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GCS Problem Report 


ace I of 2 


2. Planet: 


3. Discovery Date: 
12-28-94 


4. Initiator & Role: 
Quacli/Tcstcr 


5. Activity at Discovery: 


* Activity 

DR I CR I RC I RS I TRR 1 TCR I ICC I TCE | R 


Developmenlj’hj]jgg|^ l_jjR__^^j^^^^^J_J5S__^TO^^^K^^^KA^^ujj^_ 

Design 

Code pBB T 1 IHI IHi HIH _ 

Unit Testing ^ — 

Functional ^ — 

Structural ^ 

Subframe Testing ^ 

Frame Testing ^ 

Top-Level 

Integration Testing 

ft. Description of Problem: 

Testing on GP functional unit revealed the following: 

1 ) In the Subroutine AVG_ATT, the wrong index were used to perforin the calculation. 

2) While computing the second estimate of the RK algorithm: 

a) The last step of the velocity estimate multiplies the wrong variable with the step- 
size 

b) While calculating the derivative Tor altitude, the altitudc(2) is averaged into the 
previous estimate instead of adding 50% of the previous estimate. 

3) While computing the third estimate of the RK algorithm, the derivative Tor the altitude 
repeats the averaging error as #2b) 

4) In computing the forth estimate of the RK, the velocity calcuation multiplies the wrong 
variable with step-size 


Configuration Item: 
PLUTO Source Code 


7. Artifact Identification: 

Design Description Support Documentation Configuration Item: 

~X Source Code _ Other PLUTO Source Code 

Fxecutable Object Code 

8. Test Case Identification: GP_NRJ)0l, TSP_NR_00 1 -003, TSP_ROJ)04-(K)5, TSP_NRJH)6-(X)7, TSP_RO_()08-0l I, 

RFCLP_NR 001, TDRLSP RQ_026, ARSP_NR0I7. ARSP_NR_022, ARSP_NR_023 

9. History Log: AR 

Date To Date From Person Comments _ Q* 

. 1 1 *jW / / /O/^ Terris ^ 

~ Havhurst ~7isfrWl -Worker . -tWrt.f.'i Arhcn tty'' I /"*•->■ *a ir - v<| 3 - 

1 1 1 I tb-e 

10, Total ft of Changes: if I L Total ftof No Changes: — , 

12. Initiator Sipnatiire A Date. 15. SOA Signature & Date 

Original Signed by 9 T Original Signed by l//5/9bi_ 

Patrick Quach Kelly Hayhurst 

♦ Activity DR - Design Review; CR - Code Review; RC - Reading Code; KS - Reading Sfifccification; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 


■ <u Ar.lit 
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Problem Report Continuation 


page 2 of 2 


a. Report #: 24 

b. Notes/Explanation (Please reference appropriate section number): 

Testing on RECLP functional unit revealed the following: 

1 ) The lower and upper bounds for the variable THETA is listed backwards in the 

CONSTANT.FOR file thus causing erronous printing of out of bounds messages. 

Testing on TSP revealed the following: 

I ) The upper and lower parabolic functions are expecting real variables but are in some 
cases receiving integer parameters. 

Testing on TDLRSP revealed the following: 

I ) The next TDLR state is incorrectly set for cases where the value current TDLR state is 
the invalid equivalence class TDLR_STATE.3 

Testing on ARSP revealed the following: 

I ) AR_ ALTITUDE is not accurately calculated in cases where AR_COUNTER is used. 


in 
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GCS Action Report 


, A Z J- 2 Planet- I 3. Date of Action: I Kespoiiuc.i oc 

# '24.\ Pluto 1 Jan. 10, 1995 | Reader/Moms 

!l Art DcsignDes^fpti^ _ Support Documentation Configuration Item: 

X Source Code Other 

Executable Object Code 

6. Description of Action 

The following actions were taken to correct inaccuracies and deficiencies in the Pluto code pertaining to 
problem report it 24 . 

1) In GP.FOR in the subroutine AVG_ATT, all the index values for ATT_1 and ATT_2 were changed to 
correspond with the same indices as used for the variable RESULT. 

2) In GP.FOR in the second estimate of the RK algorithm ATT K2 was changed to' VELJC2 to multiply 
the step-size. Also changed the division placement for calculating the derivative for altitude. 

3) In GP.FOR in the third estimate of the RK algorithm, the division by 2 for ? a ’ c | a ^ 1 ’ t » ^ e r i v a t i v e 
for altitude was moved to inside the parenthesis so that the correct value is passed into the DERIV_ALT 

subroutine. 

4) In GP.FOR, the fourth estimate of the RK algorithm calls the MULT VEL subroutine with the wrong 
variable. The ATT.K4 was changed to VELJC4 to multiply the step-size in the call to the MUL1_VEL 

subroutine. 

5) In CONSTANT.FOR, the lower and upper bounds for THETA were changed. 

The lower bound was changed from 3.14... to -3.14... 

The upper bound was changed from -3. 1 4... to 3. 1 4... 

fit In TSP FOR the variable, REAL TH ER MO_TEM P was added and the calls to the lower and upper 
parabolic funcilons that previously passed integer variables were changed to pass the real variable declared. 
This insures a proper casting for the function. 

7) In TDLRSP.FOR, the a qualifier was added to the else branch for determining 
FRAME_BEAM_UNLOCKED. This more accurately implements row 3 of table 5.1 1 in the i>pec. 

"else" was replaced by: 

elseif (tdlr_state = beam_unlockcd) 

8) In ARSP.FOR the equation that calculates the altitude based on AR-COUNTER uses the constant 
"3E08". It was changed to "3D08" to more accurately calculate the AR_ALI 1 1 UDb. 

Extra) In ARSP.FOR, 'ASP' was changed to 'ARSP' in all the calls to the RANGE CHECK subroutine. This 
allows the correct functional unit name to be printed when displaying the upper and lower bounds hm 
exceeded messages. 


page 1 of 1 

- 4. Respondent & Role: 

Reader/ Morris 

Configuration Hem: 


7. Was the action related to another action(s)? _X_ 


X_ Yes AR#(s) 23 
No 

I don't know 
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GCS Problem Report 



2. Planet: 


3. Discovery Date: 
1-12-95 


4. Initiator & Role: 
Quach/Tcstcr 


5. Activity at Discovery: 


Development Phases 
Design 

Code 

Unit Testing 

Functional 

Structural 

Subframe Testing 

Frame Testing 

Top-Level Simulator 
Integration Testing 


* Activity 

RS I TRR 1 TCR I TCC I TCE 


6. Description of Problem: 



Testing on CP functional unit revealed the following error: 

The three calls to the CRC16 subroutine passes the portion of the record that contains only the 
subframe specific data. According to the Spec., the Synchronization Pattern and the Sequence 
Number should also be considered in the CRC generation. 


7. Artifact Identification: 

Design Description 

X Source Code 

Executable Object Code 


Support Documentation 

Other 


Configuration Item: 

PLUTO Source Code: CP.FOR 


8. Test Case Identification: CP_NR_001, CP_NR_002, CP_NR_003, CP_NR_004, CP_NR_005 



10. Total # of Changes: Z- 


12. Initiator Sipnalnre A Data 


11. Total# of No Changes: 


I 13. SOA Sip nail ire. Jk Dale. 


, Original Signed by I Original Signed by l/l^/ ( rS'" 

Patrick Quach Kelly Hayhurst I ' 

* Activity: DR - Design Review; CR - Code Review; RC - Reading Code; RS - Reading Specification; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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GCS Action Report 


lagelofl 



6. Description of Action 


The following actions were taken to correct inaccuracies and deficiencies in the Pluto code pprtaining to 
problem report #25. 

1) In CP.FOR, the three calls to the CRC16 function have been changed so that the entire PACKET is 
sent to CRC generation function instead of just the .sp, .gp, or .clp portions. The following changes were 
made: 

.... - CRC 16 (PACKET.sp,K$SP_SIZE) changed to ...= CRC 16 (PACKET.PACKET,K$SP_SIZE) 

.... = CRC16 (PACKET.gp,K$GP_SIZE) changed to ...= CRC 16 (PACKET.PACKET,K$GP_SIZE) 

.... ■=■ CRC 16 (PACKET.clp,K$CLP_SIZE) changed to ...= CRC 16 (PACKET.PACKET,K$CLP_SIZE) 

Extra) In the CRC 16 function, entry #229 or the CRC16_TABLE has a typographical error. It should be 
"8BC1 " instead of "88C1 ". This change is made to make the table agree with Table 6 of the report on which 
the PLUTO CRC algorithm is based. The report is: 

"Byte-wise CRC Calculations", Aram Perez, IEEE Micro, June 1983 p.40. 


7. Was the action related to another action(s)? Yes AR#(s) 

X No 

1 don't know 
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GCS Problem Report 


2. Planet: 


3. Discovery Date: 
2-13-95 


4. Initiator & Role: 
Quacli/Tcstcr 


5. Activity at Discovery: 


* Activity 

Design ^ ^ 

Code f— I | HHiHlHi 

Unit Testing ^ 

Functional ^ 

Structural ^ 

Subframe Testing ^ 

Frame Testing 

Top-Level Simulator ^ 

Integration Testing 

6. Description of Problem: 

In preparation for frame and subframe testing, the following errors were found in the PLUTO 
subframe and frame level routines: 

1 ) In CLPSF.FOR: There is Typo which prevents the linker to complete. Namely the 

"CALL AELCP" 
should be 

"CALL AECLP" 

2) In PLUTO.FOR: There us a line of dead code that should be commented out. The following is ineffectual: 

”100 Continue" 


7. Artifact Identification: 

Design Description 

X Source Code 

Executable Object Code 


Support Documentation 

Other 


8. Test Case Identification: CLP_001-014, FRAME_00 1-009 


Configuration Item: 

PLUTO Source Code: CLPSF.FOR & 
PLUTO.FOR 



10. Total tf of Changes: 

12. Initiator Signature & Date 


11. Total ft of No Changes: 

I 13. SOA Signature A Dale 


. Original Signed by 9 -lS~ 9Sr Original Signed by 

” Patrick Quach Kelly Hayhurst ' ' 

* Activity- UK - Design Review; CR - Code Review; RC - Reading Couc; tor- Reading Specification; TRR - Test Readiness 
Review- TCR - Test Completion Review; TCC - Test Case Creadon; TCE - Test Case Exccudon; R - Regression; O - Other. 
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GCS Action Report 


1. AR #: 

26,1 

2. Planet: 

Pluto 

3. Date of Action: 
Jan. 13, 1995 

4. Respondent & Role: 

Reader/Morris 

5. Artifact Identificat 

Design Descrip 

X Source Code 
Executable Obj 

ion: 

tion Support Documentation Configuration Item: 

Other 

ect Code 


6. Description of Action 

The following actions were taken to correct inaccuracies and deficiencies in the Pluto code pertaining to 
problem report #26. 

1) In CLPSF.FOR "CALL AELCP" was changed to "CALL AECLP". 

2) In PLUTO.FOR the dead code "100 Continue" was removed. 


7. Was the action related to another action(s)7 


_ Yes AR#(s) 
X No 

I don't know 
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GCS Problem Report 


1 1. PR 

' 27 

2. Planet: 

Pluto 

3. Discovery Date: 
3-10-95 

4. Initiator & Role: 
Quach/Tcstcr 

1 j. Activity at Discovt 
1 _Dc 

:ry: 

vclonmcnt Phases II DR 

+ 

1 CR 1 RC 1 RS 1 

Activi 

TRR 

T TCR 1 TCC 1 TCE I 

JLJJU 



Design 


Code 


Unit Testing 


Functional 


Structural 


Subframe Testing 


Frame Testing 


Top-Level Simulator 
Integration Testing 



6. Description of Problem: 

In executing trajectory test cases, the following error was discovered in Pluto's ASP functional unit: 

1 ) 


Minute floating point errors in the mean calculations can cause the A_STATUS to be set incorrectly for the case 
where the three elements to average arc identical. 


In reviewing Pluto's ASP functional unit, the following was discovered. 

2) The standard deviation is not implemented exactly as indicated in the GCS Specification, although it is a correct 
calculation for standard deviation, it leaves open the possibility that the software will fail as a result of a negative 


square root. 


Trajectory test cases indicate that table 5.9 and 5.10 have a potential negative square root calculation. Modification to the 
Spec, necessitates tlie following modification to the GP functional unit: 

3) The Lcfi-hand-sidc of tlie MAX-NORM AL- VELOCITY compare has been changed to include a MAX function. 
The Plulo code should be likew ise updated. 


7. Artifact Identification: . 

Design Description _ Support Documentation ConfiguratHin Item: 

jj_ Source Code _ Other PLU 1 0 Source Code: ASP.FOR, C.P.hOR 

Executable Object Code 

8. Test Case Identification: TRAJ_TD_019, 1 RAJ_1 D_02l 

9. History Lof 
Dnln Tn 

Date From 

Person 

Comments 

ARff 

■O in OCT 


V Becher 

Ar.-rlT^mK r^J F Sk-n piabl<»nryS i o -S/^fr - rr^lli.iSj 


LU. 1 »3 — 


a — 

'lA -<.p er ffXnA (2. Ji3 " - 



WSDBEBk 



2SF > 1 — 

imvmraa 

HEmjzna 




10. Total ff of 

- > ■ yi » — 

Changes: _£L 

1 1 . Total ff of No Changes: 


Original Signed by 
Patrick Quach 




Original Signed by 
Kelly Hayhurst 




Aclivily UK - ucsign Review; CR - Code Review; RC - Rending Code; KS • Rending Specincate: TRR - Tea Rcndincss 
Review; TCR - Test Complete Review; TCC - Test Case Creation; TCE - Tea Case Excenuon; R - Regression; O - Other. 
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GCS Action Report 


I. AR #: 
27.1 


2. Planet: 


Pluto 


5. Artifact Identification: 

X Design Description 
X Source Code 

Executable Object Code 


3. Date of Action: 

Mar. 16, 1995 


Support Documentation 
Other 


page 1 of 1 

4. Respondent & Role: 

Programmer/Morris 

Configuration Item: 

ASP.FOR, GP.FOR 

'p 'iru-i l *> ,7 'if*** 3- :3 - 


6. Description of Action clfV t 

The following actions were taken to correct inaccuracies and deficiencies in the Pluto code/pertaining to 
| problem report #27. 

1 1 In ASP.FOR the determination of A_STATUS was altered to set A.STATUS correctly for cases when 
the three elements to average are identical. The Pluto design (P-Spec 1 .3) was changed to indicate that the 
mean and standard deviation is claculatcd only if all A_STATUS values are healthy and all three previous 
A ACCELERATIONS are not identical. This reflects the change in the Spec. Mod. 2.3-7. 


2) In ASP.FOR the standard deviation calculation was changed to a mathematical equivalent to remove 
the possibility of taking the square root of a negative number. 

3) In GP.FOR a MAX function was added to the left hand side of both instances of comparison with 
MAX-NORMAL-VELOCITY. The Pluto design (P-Spec 2.2) was changed to reflect the change in the Spec. 

Mod. 2.3-7. 


7. Was the action related to another action(s)? 


_ Yes AR#(s) 
X No 

I don't know 
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GCS Problem Report 


2. Planet: 


3. Discovery Dale: 
4-6-95 


4. Initiator & Role: 
Quacli/Tcstcr 


5. Activity at Discovery: 


* Activity 

Dcvcjogmcnt_PhasK_J!_DIl__^^^^^^^^l_RS__^T^^^^X^^^rc^^^K^ R 
Design 

Code pBML____L IH 

Unit Testing — — 

Functional ^ 

Structural ^ 

Subframe Testing ^ 

Frame Testing ^ 

Top-Level 

Integration Testing ^ 


6. Description of Problem: 

The Pluto source code Tiles do not have the proper end of line characters. This resulted in syntax errors during compilation using 
the VAX FORTRAN compiler. 



7. Artifact Identification: 

Design Description 

X Source Code 

Executable Object Code 

8. Test Case Identification: 


Support Documentation 
Other 


Configuration Item: 

PLUTO Source Code: all files 


9. History 


|HnDRE9Etn^9H 

BsmeeiEini^B 


Person I 


Comments 


ARff 


<2B 



•//<-/ 




10. Total tf of Changes: I 1 1 . I otal it of No Changes. — 

12. Initiator Sienatnre A Dale 13. SO A A j I 

Original Signed by ftzAll£ ^ Original Signed by 

— Ptrik Ouach Kelly Hayhurst 

* Activity" DR - Design Review; CR - Code Review; RC - Reading Code; R5 - RKiding’Spccification; TRR - Test Readiness 
Review; TCR - Test Completion Review; TCC - Test Case Creation; TCE - Test Case Execution; R - Regression; O - Other. 
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GCS Action Report 


page 1 of 1 


iKsaanHH 

2. Planet: 

3. Date of Action: 

4. Respondent & Role: 

■H H 

Pluto 

Apr. 6, 1995 

Tester/Quach 

I 5. Artifact Identification: 1 


Design Description Support Documentation Configuration Item: 

X Source Code Ollier All pluto source code files 

Executable Object Code 


6. Description of Action 

The following actions were taken to correct inaccuracies and deficiencies in the Pluto code pprtaining to 
problem report #28. 

All Pluto source code files have been retrieved again from the SUN system where they are deposited 
by the programmer before transfering into CMS on the VAX system. The following File Transfer Protocol 
(FTP) command was used to get the files: 

mget *.for 

The FTP session was initiated on the VAX using its default FTP settings. The following files were transfered 
to a VAX directory: 

AECLP.FOR 

ARSP.FOR 

ASP.FOR 

CLPSF.FOR 

CONSTANTS. FOR 

CP. FOR 

CRCP.FOR 

EXTERNAL.FOR 

GP.FOR 

GPSF.FOR 

GSP.FOR 

GUIDANCE_STATE.FOR 

PLUTO.FOR 

RECLP.FOR 

RUN_PARAMETERS.FOR 

SENSOR_OUTPUT.F0R 

SPSF.FOR 

TDLRSP.FOR 

TDSP.FOR 

TSP.FOR 

UTILITY. FOR 


7. Was the action related to another action(s)? Yes ARW(s) 

X No 

I don't know 
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Appendix F : Support Documentation Change Reports for the Guidance 
and Control Software Project 


This document was produced as part of Guidance and Control Software (GCS) Project conducted at 
NASA Langley Research Center. Although some of the requirements for the Guidance and Control 
Software application were derived from the NASA Viking Mission to Mars, this document does not 
contain data from an actual NASA mission. 


F-l 






Support Documentation Change Report 


1. Configuration Item Verification Plan 



page 1 of _ 

3. Formal Modification #: 


4. Part of Configuration Item Affected: Appendix Design Review Checklist 


5. Reason for Modification: It was discovered during a Design Review the following 
modification was needed to identify cases where input/output variables may be used in a 
process, but are not defined by the process where they are used. 


L 

i 


6. Modification: In the Data Usage section, add item number 7. 

7. Are all the input/output variables of a process defined in the INPUT/OUTPUT section of the 
design P-SPEC for that process? 


7. SQA Signature & Date: 


Original Signed by 
Carlos Liceaga 


■ 7/2 1 / 9 ') 
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Support Documentation Change Report 


page 1 of 1 

.Configuration Item Verification Plan 2. Date 3. Formal Modification #: o 

7/29/93 

4. Part of Configuration Item Affected: Appendix Design Review Checklist, Date Usage section, 
item #3 


5. Reason for Modification: In order to comply with the Software Development Standards change 
to Design Documentation section, subsection II. Design Structure, paragraph e) Data Dictionary 
regarding additional variables in the design. 


6. Modification: Data Usage 

3. If the design includes variables in addition to the global data store variables defined in the GCS specification, and 
these variables represent flows between processes, are they included in the design data dicitonary? 








Support Documentation Change Report page 1 of _L 


Configuration Item: 

y y/2. I o 


2. Date: 


3. Formal Modification I/: 

3 » 


4. Part of Configuration Item Affected: 

D£J>H6^ 


f ft OCL 'in.'- iZ t 'i> 


5. Reason for Modification: 

fy^o L b. iv^ 4 1 


6. Modification: 

\ . " A '^' u ^ jL*&S 

/v x o cb. u~ A - .- i . 


9. 


-5 Cj A cbtL'h j~z> J'-f -i, 


b C^v rjL-J' 


f*Y° 




(\-L^O C 


,i ,/i ■■:.) 1 ‘ , < ' j*. i 1 6 OVX. \Vv C ^ 1 

x , ■; “ f ‘- ‘ ^ r ,3 y 


/<- (l- ‘ 


'V' 


7. SQA Signature & Dale: 

Original Signed by 
George Finelli 


Original Signed by 
Carlos Liceaga 


:;/:y 


<#3 
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Support Documentation Change Report 


Page 


I et 1 


1. Configuration Item: 

Software Verification Plan 


12. Date: 


I 


1 3. Formal Modification tt: 4 


I 


I 09/09/93 


4. Part of Configuration Item Affected: 
Design Review Procedures 


5. Reason for Modification: 

Change in SQA role in Design Review Procedures 


6. Modification: 

Corrections were made to die Review Team members, removing die SQA from the team. The SQA was also removed 
from the Inspector section of die document. 


7. SQA Signature and Date: Original Signed by 

George Finelli 


‘thliA 
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Support Documentation Change Report 


page I of L 


1. Configuration Item: 

2. Date: 

3. Formal Modification #: 5 

Software Verification Plan 

12/28/93 


4. Part of Configuration Item Affected: 
Code Review Sections 




5. Reason for Modification: 

Insert the documentation for Code Review Overview, Code Review Procedures and Code Review Checklist. 
Correction to the Inspection Log in order to distinguish between the different Inspections, Design and Code. 


6. Modification: 

Added the documentation for Code Review Overview, Code Review Procedures and Code Review Checklist, (see attached sheets) 
Correction to the Inspection Log in order to distinguish between the different Inspections, Design and Code, (see attached sheet) 


7. SQA Signature & Date: original Signed by 

1 George Finelli 
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Support Documentation Change Report 


page 1 of 35 


1 1. Configuration Item: 

2. Date: 

3. Formal Modification ft: 6 

Software Verification Plan 

( 

3/17/94 



4. Pari of Configuration Item Affected: 

The Design Review Procedures and Code Review Procedures will be modified into one section called the Review Procedures. The 
Test Phase documentation will be added. 


5. Reason for Modification: 

There was loo mueh repetitious information in the Design Review Procedures and the Code Review Procedures, so a new combined 
section , The Review Procedures, will be added. The Testing Plan will be added as well as a copy of the Problem Report. The font 
and page formatting were changed to make the document more readable. The copy of the PR document will be added later, due to 
formatting problems. tfcj x (~ 1 f 


6. Modification: 

A new version of the Software Verification Plan has been created. This new version of the Review Procedures replace the Design 
Review Procedures and the Code Review Procedures, eliminating the redundancies in these documents. The Testing Plan„R R form ' 
were added. Modification to the Traceability Matrix added the Test Case column. General clean up was also performed, including 
formatting and font changes. Corrections attached. 


SQA Signature & Dale: 0rigina| signed by — S'/s/W 

Kelly Hayhurst — 


/ 
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Support Documentation Change Report 

page 1 of 1 

1. Configuration Item: 2. Date: 3. Formal Modification #: 7 ™ 

Software Verification Plan 5/31/94 

4. Part of Configuration Item Affected: 

A table of content will be added into the document and all the text rearranged to conform with the table of contents. 


5. Reason for Modification: 

The current plan docs not contain all topics and considerations required by DO-178B. The Test Overview section will be 
reorganized into Testing Activities. The Transition Criteria section and Reverification Guidelines section will be added. This 
modification will make the plan more accurately reflect the requirements listed in DO-178B for a verification plan. 


6. Modification: 

A table of contents has been added. Portions of the document have been reorganized to correspond with the table of contents and to 
address the issues required by DO-178B. Specifically, The Verification Methods section has replaced die Review and Analysis 
Overview and die Test Overview Secuons. 

References arc cited for verification tool descriptions and accordingly added to die reference listing. 

The Traceability Matrix has been updated. 
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Support Documentation Change Report 


2. Date: 
12/6/94 


3. Formal Modification #: 8 


page 1 of 1 

I . Configuration Item: 

Software Verification Plan 

4. Part of Configuration Item Affected: 

1. Testing Activities section of the document 

2. Traceability Matrix 

3. Table of contents 

5. Reason for Modification: 

1 . Make the Testing section of this document constant with Tl.e Software Cases and Procedures document 

2. Traceability Matrix 

3. Add a useful table of contents 


6. Modification: 

| ES ^ ^ ' “ *• *1 nxis, when ,he 

existing Software Verification Plan w^ rented A ? f‘mx has-been updated and expanded. The old copy in the 

| Software Verification Cases and Procedures documents. A new InJnSS^ ar ° "° W covcred in ll “ 


7. SQA Signature & Date: 


Original Signed by 
Kelly Hayhurst 
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Support Documentation Change Report 


page 1 of 1 


1. Configuration Item: 

2. Date: 

3. Formal Modification #: 

Verification Cases and Procedures Document 

12-21-94 

2 

4. Part of Configuration Item Affected: 

Test case development procedure and test case execution procedure. 




5. Reason for Modification: 

DO-178B requires test cases and procedures for high-level requirements. Test case development and execution procedures will be 
clarified. Trajectory testing needs to be added. 


6. Modification: 

1) The test case development procedure has been modified to include step by step procedure 
for regenerating test-input and expected results files. 

2 ) The trajectory test development procedure has been added 

3 ) Tables listing all the files involved in the testing process has been added. 

4 ) Filenames used in the procedure have been checked for consistency with CMS. 


7. SQA Signature & Date: 



Original Signed by 
Kelly Hayhurst 
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Support Documentation Change Report 


page 1 of 1 


1. Configuration Item: 

2. Date: 

3. Formal Modification #: 9 

Software Verification Plan 

4/19/95 


4. Part of Configuration Item Affected: 

1. Test Coverage Overview 

2. Appendix A 

3. Table of contents 

5. Reason for Modification: 



The Verification Plan should be modified so that it contains test coverage issues and no procedural descriptions. Trajectory testing 
should be addressed in the document. The Table of Content must be updated to reflect this change. The list of authors need to be 

updated. 




6. Modification: 

The verification plan has been modified to address coverage issues. All procedural information has been moved to the Verification 
Cases document. The table of contents has been changed accordingly. The author list has been updated. 


7. SQA Signature & Date: 


Original Signed by 
Kelly Hayhurst 
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Watts’ 
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CM PLAN 



Support Documentation Change Report 




page 1 of 1 

1. Configuration Item: 

2. Date: 

3. Formal Modification #: 

Configuration Management Plan 

8/31/93 

4. Part of Configuration Item Affected: 

Table 8: Configuration Identification for the D0178-B Life Cycle Data 


5. Reason for Modification: 




Clarification of configuration items. 


6. Modification: 


The Design Description has been broken into two configuration items for configuration management purposes; they will be 

“ n ' a ' neJ in tlie same CMS librar y unt *er different element names. Also, since the Spec had formal mods written before the 
SDCR lorm was in place, the CM Plan needs to reflect this. 

Old Text: 


Design Description* 

Design Description 

11.10 

Problem and Action Reports* 
Support Document Change Forms 

Problem Reports 

11.17 

Modified text: 

Teamira/L Model* 
Design Overview* 

Design Description 

11.10 

Problem and Action Reports* 

Support Document Change Forms 
Formal Modifications to the Specification** 

Problem Reports 

11.17 


ut mi, wcic nui icLorueu on a support L/ocutr 

Change Report (SDCR) form. All remaining modifications to the GCS Spec will be recorded on a SDCR form. 


7. SQA Signature & Dale: 


Original Signed by 
Carlos Liceaga 


lit 93 
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Support Documentation Change Report 


page 1 of 


. . Configuration Item: 

2. Date: 

3. Formal Modification #: 

Configuraiion Management Plan 

VI 8/94 

oL 

4. Part of Configuration Item Affected: 
Entire document 




5. Reason for Modification: 

Need to change number of implementations from three to two and remove any references to Earth implementation. 


6. Modification: 


OLD (section "The Role of SCM in the GCS Project"): 

The GCS project involves independent production of three implementations of a guidance and control 
application where the development process for each implementation follows the DO-178B guidelines. The 
three GCS implementations are referred to by planetary names: Mercury, Earth, and Pluto. When there is a 
need to distinguish multiple implementations, the word planet will be used to refer to Mercury, Earth, or 
Pluto. For this project, the configuration environment and activities must provide for the management of 
the life cycle data for one development process and must also provide a mechanism to preserve the 
independence of the life cycle data for the multiple implementations. This plan will address the 
configuration management process for life cycle data from all three GCS implementations. 

NEW: 

The GCS project involves independent production of two implementations of a guidance and control 
application where the development process for each implementation follows the DO-178B guidelines. The 
two GCS implementations are referred to by planetary names: Mercury and Pluto. When there is a need to 
distinguish multiple implementations, the word planet will be used to refer to Mercury or Pluto. For this 
project, the configuration environment and activities must provide for the management of the life cycle data 
lor one development process and must also provide a mechanism to preserve the independence of the life 
cycle data for the multiple implementations. This plan will address the configuration management process 
for life cycle data from both GCS implementations. 


7. SQA Signature & Date: 0rjgina] signed by 

Kelly Hayhurst 
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Support Documentation Change Report Continuation 

page .7^ ol ^ 

Fm X -(W Cm p Ian 

b. Notes/Explanation (Please reference appropriate section number): 


OLD (section "SCM Environment"): 

Since three GCS implementations are being independently developed, there will be data from each of the 
three implementations in some cases. For example, each implementation will have its own source code 
(e.g., Mercury Source Code, Earth Source Code, and Pluto Source Code). 

NEW: 

Since two GCS implementations are being independently developed, there will be data from each of the 
implementations in some cases. For example, each implementation will have its own source code (e.g., 
Mercury Source Code and Pluto Source Code). 



Support Documentation Change Report 




page 1 of 1 

1. Configuration Item: 

2. Date: 

3. Formal Modification #: 

Configuration Management Plan 

5/18/94 

3 

4. Part of Configuration Item Affected: 
Entire document 



5. Reason for Modification: 




The source code phase is no longer transitional; therefore, need to remove references to transitional source code phase and modify 
text appropriately. 


6. Modification: 

Modification 1: 

Modification 2: 

Modification 3: 

Modification 4: 

Modification 5: 
Modification 6: 


Deleted the term "transitional" from the phrases "transitional coding" and "transitional software 
coding" in 4 occurrences: twice in section The Role of SCM in the GCS Project of the 
Introduction and twice in section Baselines and Traceability of the SCM Activities. 

Deleted reference to Post-Code Review version of code in 6 occurrences: once in section 
Procedures for Using CMS of the SCM Environment, three times in section Baselines und 
Traceability of the SCM Activities, and twice in Transition Criteria. 

The transitional software design process is complete when the design has been verified and 
approved by the SQA. The coding phase is complete when the code has been verified and 
approved by the SQA (in section The Role of SCM in the GCS Project of the Introduction). 

The source code libraries and the executable object code libraries will start after the design phase 
is completed instead of being created from the Post-Code Review version received from RTI (in 
section CMS Libraries of the SCM Environment). 

Removed RTI Post-Code Review and Original Transition Code milestones from the source code 
baselining schedule (in section Baselines and Traceability of the SCM Activities). 

Changed source code and executable object code transition criterion from Post-Code Review 
version received from RTI to Design Phase Completion in Table 9. 


7. SQA Signature & Date: 


Original Signed by 
Kelly Hayhurst 
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Support Documentation Change Report 


page 1 of 2 


i. Configuration Item: 

2. Date: 

3. Formal Modification #: 

Configuration Management Plan 

5/19/94 

4 

4. Part of Configuration Item Affected: 
Entire document 




5. Reason for Modification: 


1. Remove references to concurrent/noconcurrent qualifier in CMS libraries. The Configuration Manager now uses DEC windows 
interface with CMS which works differently than the CMS subsystem command level which was previously used. 

2. Change the information the GCS participants must supply the CM. 

3. Change Configuration Manager's room number. 

4. Remove reference to current GCS specification version (otherwise, the CM Plan would have to be updated with each new Spec 
version). 

5. Miscellaneous mods: grammatical errors, spacing in tables, etc. 


6. Modification: 

Modification 1 . Removed references to the concurrent/noconcurrent qualifier. 

A) Removed the following statements : 

• All elements in the CMS libraries will have the concurrent qualifier disabled; this will ensure that two project 
participants are not working on the same element at the same time and making separate changes to the 
element (from section CMS Description). 

• The element is marked within the CMS library that it is reserved so that no other concurrent reservations may 
be made during this time (from section CMS Description). 

• As elements are created, they will have the "noconcurrent" qualifier enabled. This means that only one 
reservation of an element may exist at one time; this will ensure that two project participants are not working 
on the same element at the same time and making separate changes to the element (from section Procedures 
for Using CMS). 

B) Removed the noconcurrent qualifier from CMS example in section Procedures for Using CMS. 

Modification 2. Removed "CMS library name" from information provided to the Configuration Manager when 
requesting a reservation in 3 occurrences: once in the section Procedures for Using CMS, once in the section 
Change control, and once in the section Change Review. ' 

Modification 3. Now refer to "Configuration Manager's office" instead of specific room number. Changed once 
in the section Other SCM Tools and twice in the section Configuration Status Accounting. 


7. SQA Signature & Date: original Signed by 
Kelly Hayhurst 
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Support Documentation Change Report Continuation 


page _2_ of _2_ 


a. Report #: 4, for the Configuration Management Plan 


b. Notes/Explanation (Please reference appropriate section number): 

Modification 4. Removed reference to current GCS specification in the following paragraph: 

In some cases, a new baseline may be established for a support document if numerous modifications have 
been made (since no predefined milestone exists). For example, when the GCS specification was first 
developed, Version 1.0 was created. There were a few interim versions of the GCS specification (Version 
1.1, 1.2, etc.) created before it was classified as Version 2.0. After verification of the GCS specification, it 
was updated to Version 2.0. After a significant number of specification modifications, the GCS specification 
was updated to Version 2.1. Now that the GCS project has been transferred to NASA, numerous 
modifications have been made to the GCS specification and it is now at Version 2.2. (in the section 
Baselmes and Traceability) 

Replaced the bolded sentence with: Upon transfer to NASA, a number of significant modifications were 
made to the GCS specification, and Version 2.2 was released at the end of the transitional software 
requirements development phase. 

Modification 5. Miscellaneous mods. 

• Removed "CC1" from the titles of Table 3 and Table 4. 

• Changed the sentence "In case of an unusual occurrence, a red will be entered in the log with a number 
associated with it; an explanation of this occurrence will be on a separate page in the binder." to "In case of an 
unusual occurrence, a will be entered in the log with an explanation of the occurrence." in the section 
Configuration Status Accounting because the status logs are also available via Excel spreadsheets. 

• grammatical errors corrected 

• realigned some tables 

The following paragraph should have been modified with SDCR #3 for the Configuration Management Plan: 

OLD: 

The support documents enter CMS when the initial draft of the document has been approved by the SQA 
representative, with the exception of the GCS specification. The development products enter configuration 
management process at the Post-Code Review version received from RTI (see the chapter "SCM Environment" in 

is document for a list of the support documentation). Table 9 shows the transition criterion for entering the 
configuration management process for the project data. ° 

NEW: 

The support documents enter CMS when the initial draft of the document has been approved by the SQA 
representative, with the exception of the GCS specification. The design descriptions enter the configuration 
management process at the Post-Code Review version received from RTI. The source code and executable object 
code are generated and then enter die configuration management process after the design phase has been 
completed. Table 9 shows the transition criterion for. entering the configuration management process for the 
project data. 
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Support Documentation Change Report 




page 1 of 1 

1 . Configuration Item: 

2. Date: 

3. Formal Modification #: 

Configuration Management Plan 

12/19/94 

5 

4. Part of Configuration Item Affected: 
Problem and Change Reporting section 



5. Reason for Modification: 




There have been a number of changes in the procedures that are followed for problem reporting. This needs to be reflected in die 
document. 


6. Modification: 


The following section and figures were modified to show diat the project leader has control of the assignment of PR's. 

• Instructions for Problem and Action Reports 

• Figures 3: Flow of Problem Reporting Process for the Development Products 

• Problem Reporting for Support Documentation 

• Figure 5: Flow of Change Reporting Process for die Support Documentation 

• Completing die Problem Report Form 

• Completing die Action Report Form 

• Completing the Support Documentation Change Report Form 
(See die attached text for the updated changes.) 
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Support Documentation Change Report Continuation 


page _2_ of _2_ 


a. Report #: 6 


b. Notes/Explanation (Please reference appropriate section number): 

8. Deleted the old contents of the section “Procedures for Using CMS”, and added new text explaining how to fetch, reserve and 
replace elements. The new section follows: ’ 

Procedures for Using CMS 

The configuration manager will use CMS libraries to manage project data. CMS can be invoked from the DCL command 
level, from the CMS subsystem command level, or from the DECwindows user interface. 

In order to fetch, reserve or replace an element using CMS, it is easiest to have the directory set to the specific 
directory in which the element will be placed or retrieved. The fetch command is issued when a copy of the element is 
needed for examination purposes only; no changes may be made to this copy of the element. For example, after issuing the 
fetch command, the element name is entered in the appropriate place. If this transaction needs to be recorded in the history 
log, a remark must be entered before the command is executed; otherwise, no transaction will be recorded. Once the fetch 
command has been issued, the element will reside in the VMS default directory that was set prior to issuing the command. 
The reserve and replace commands work in a similar manner, except these transactions are always recorded in the history 
log, even if no remark is entered along with the command. The reserve command places a working copy of the element in 
the directory; the latest version of the element is reserved unless otherwise specified. If the noconcurrent qualifier was 
issued at the time of reservation, no other reservations of that element are allowed until after the element has been replaced. 
Once the reserve command has been issued, the element name is entered, along with a remark, and then the reservation is 
executed. The replace command can only be executed if a reservation exists. The replace command, along with the element 
name and remark, are entered and executed. If there is more than one version of a file in the default directory, the replace 
command will use the highest version number for the replacement of an element. 

The wildcard character, may be used for multiple reservations, replacements, or fetches if the elements are 
similar in name. The * may be used in place of one or more characters. 

The following section describes the tool team work, which will be used by the programmers for the development of their 
detailed designs in addition to CMS. 
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1 1. Configuration Item 

Software Development Standards 


page 1 of L 


2. Date 

7/27/93 


3. Formal Modification #: 


4. Part of Configuration Item Affected: 


Chapter: Software Design Standards, Section: Design Documentation, II e) 


5. Reason for Modification: ~ ~ “ ~~ 

Need to clarify the wording regarding the contents of the Data Dictionary. 

Propose that the Data Dictionary should contain all entries from the Data Dictionary^ the GCS 
specification and any additional variables contained in the design that represent data flows between 
processes. 


6. Modification: 


Action: Replace the following text with the modified text, 
e) Data Dictionary 

This subsection should contain a complete data dictionary, including both specified and non- 
specified variables. This subsection may also contain all the information pertaining to resource 
limitations, such as memory and timing constraints. 

Modified Text: 

e) Data Dictionary 

This subsection should contain the data dictionary for the teamwork design. This data 
dictionary should include all of the data dictionary entries in the GCS specification and any 
additional variables contained in the design that represent flows between processes. This 
subsection may also contain all the information pertaining to resource limitations, such as 
memory and timing constraints. 
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2. Date: 

yugc i m I 

3. Formal Modification #: 

8/30/93 

2 


Configuration Item: 

Software Development Standards 


4. Part of Configuration Item Affected: 

Chapter: Problem and Change Reporting 

Section: Instructions for Problem and Action Reports, first paragraph 


5. Reason for Modification: " “ — 

Need to make explicit the concept that during verification activities where a Moderator is present die Moderator will have the 
authonty to make the final determination as to whether issuing a Problem Report is appropriated^ 
activities, it will not be the case that any project participant can initiate a Problem Report. 8 


6. Modification: 

Vtion: Modified the sentence below to clarify who has the authority to initiate Problem Reports 

original Text: During the development cycle any participant in the project (programmer, verification analyst SQA representative 
or system analyst) who identifies or observes something that may need to be changed in some way in a 1 
development product is responsible for initiating a Problem Report. 

Modified Text: In general, a project participant who identifies, in the course of their prescribed activities, something in a 

development product that may be regarded as a problem (such as a violation of a software requirement or project 
standard) is responsible for initiating a Problem Report. However, during those verification activities where a 
Moderator is present, the Moderator will have the authority to determine whether issuing a Problem Report is 


L 
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page 1 of 1 

Configuration Item: 

2. Date: 

3. Formal Modification #: 

Software Development Standards 

8/30/93 

3 

4. Part of Configuration Item Affected: 

Chapter: Problem and Change Reporting 

Section: Instructions for Problem and Action Reports, item 1. 



5. Reason for Modification: 




Need to clarify that during verification activities where a Recorder is present, the Recorder will be the actual initiator of the 
Problem Reports. 


"jVe'uicftl di'vWrc'.'rV t-ioy, /tvcre \rnpor lao f . llad 
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6. Modification: 
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I. Configuration Item: 

Soli ware Development Standards 


page I of I 


2. Date: 3. Formal Modification #: 

1/3/94 3 


4. Part of Configuration Item Affected: ' ' 

Chapter: Problem and Change Reporting 

lnS “, UCti r nS i° r Prob !^ m and Aclion Re P orts - Completing the Problem Report Form, Completing the Action Report Form 
loblcm Repotting lor Support Documentation, Completing the Support Documentation Change Report, Figure 6, and Figure 8 

5. Reason for Modification: ~ ' 

The GCS project leader _has assumed some of the responsibilities associated with the Problem and Aclion reportiim that Ind 
been delegated to the SQA representative. The project leader will now be the first point of contact for Problem and Action 
. ‘’T 1 D0CU , 1, ' ellta 1 tlUn ^ange Re P° rts - The Project leader will give the initial approval to make the chan-e 

reflect iTsdrmge ’ “ ^ " 1S ‘° the appropriate persons ' Need to diai ^ e Problem reporting procedures^ 


6. Modification: — ■ 

To show that several ot the problem and action reporting responsibilities that had belonged to the SQA representative now 
cJ-tnler ^"PmbfuT^ ‘r te ™ ^ re P rese,1tative " wa * replaced with "project leader" in the appropriate parts in the 

been hi^h.i^ fbmn W,th “ ^ mill ° r *° Cla,ify lhe p — Those cha ^s have 
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2. Date: 

3. Formal Modification #: 

5/6/94 

4 


I. Configuration Item: 

Software Development Standards 


4. Part of Configuration Item Affected: 

The following chapters are affected: section The Software Development Process for the GCS Project of the Introduction , 
Instructions for Programmers Regarding the Transitional Design Phase, Software Code Standards, Instructions to Programmers 
Regarding die Transitional Coding Phase 


5. Reason for Modification: 


Change in project plan: now going to have the programmers generate their own source code for the implementation instead of 
modifying existing code for the implementation developed at the Research Triangle Institute. The instructions to the programmers 
during the design and coding phases will change along with the code standards. 


6. Modification: 

Modification I : Deleted the term "transitional" from the phrases "transitional coding" and "transitional software coding" in 

3 occurrences: once in section The Software Development Process for the GCS Project of the Introduction and 
twice in Instructions to Programmers Regarding the Transitional Coding Phase 

Modification 2: Removed the statement "5. modification of the existing code (developed at RTI) to bring it up to the newly 
revised design" from the Introduction (The Software Development Process for the GCS Project) 

Modification 3: Deleted the following section from Instructions for Programmers Regarding the Transitional Design Phase: 

While waiting for their design reviews, the programmers should (given that there is time to do so): 

1. Reserve their original Post Code Review version of their coded implementation out of the CMS library after 

• rwer? de !' gn t0 the SQA re P resentalive - An element or class of elements can be fetched or reserved from 
the CMS library by contacting the configuration manager. When requesting an element, be specific about which 
element is needed, why that element is needed, and whether to reserve or fetch that element. VAX Notes should be 
used to request-elements lrom CMS. Note that the configuration manager will not release the Post Code Review 
version of the code until the design description has been submitted for configuration management. 

2. Alter reserving the Post Code Review version of the implementation, the programmer should remove (delete) the 
i e vision history, all code that was commented out due to changes from previous RTI-generated Problem Reports 
and comments associated with those Problem Reports from this version of code. When finished, the code should 
still have the original descriptive comments in place. No executable code should be deleted or modified at this time 
This new version of code will be referred to as the original transition code. To assure that no executable code has 
been deleted, it is suggested that the programmer use the DIFFERENCES command in VAX/VMS to compare the 
original Post Code Review version to the original transition code version. The only differences reported as a result 
of using the DIFFERENCES command should be comments. 

3. Replace the original transition version of the code back into the appropriate CMS library for the code (by consulting 
with the configuration manager using VAX Notes) prior to making any other modifications to the code. The 
elements of the original transition version of code will be put in a baseline for that implementation. 

I 
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page _2_ of 

i. Report #: 4, for the Software Development Standards ” ' 


b. Notes/Explanalion (Please reference appropriate section number): 
Section 6. Modification (continued): 


Modification 4. Moditied the entire section Code Presentation and Documentation in chapter Software Code Standards to the 
following: 


Code Presentation and Documentation 


Por this GCS project, the programmers are required to follow a tew simple guidelines with respect to the 
piesentalion and documentation of the source code. With respect to presentation standards (line length, indentation, blank 
lines, etc.), programmers are only required to make the source code easily readable to aid in verification and future 
modification. Programmers are encouraged to make generous use of indentation and blank lines, but no specific constraints 
are imposed. With respect to documentation, each programmer should add descriptive comments to the source code 
wherever appropriate. The comments should provide sufficient information to allow changes to be made completely, 
consistently, and correctly while retaining the structure. The following items also are required for the documentation of the 
souice code: module header blocks, a revision history (starting after the first Code Review), and a system for denotin" 
modifications. Below is a brief description of these items. " 

Module Header Block — Header blocks should be used at the beginning of each module to provide an overall summary of 
that module. Figure 3 shows a general format for the module header. Each programmer may choose the exact 
style of the header block; that is, the style does not have to conform precisely to the style presented in Figure 3, but 
all of the information should be included. 

Revision History— All modifications made to each module should be summarized in a section called revision history 
located directly under the header block for that module. Each modification to a module should be labeled with a 
version number, v#. For example, the first modification to a module would be labeled vl and the second 
• modification would be v2. The revision history also should contain the Action Report (AR) number associated 
with each change made to the module, the date the change is made, the name of the person implementing the 
change, and a description of the change. 

Notation of Modifications - Once the source code is submitted for code review, no code that is to be modified in 
lesponse to a Pioblem Report may be deleted. The source code that is to be modified should be commented out 
(instead ol deleted) and the new code added. The beginning of all areas of changes should be noted clearly with a 
comment line, as shown below, containing the following: 


! v# Begin changes for AR#<action report numberx <short description of change> 


The end of change aieas should be similarly marked by an "End Change" comment line. 
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page 3 of _3_ 

a. Report 4, lor the Software Development Standards 

b. Notes/Explanation (Please reference appropriate section number): 

Modification 4. continued 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! i !!!!!!!!!!!! i in j nun I ! j i j 1 1 ni | inn 1 1 1 1 
| 

! MODULE NAME: 

! PURPOSE: 

! ARGUMENTS: 

! NOTES: 

! AUTHOR: 

! IMPLEMENTATION NAME: 

! DATE FIRST SUBMITTED FOR CONFIGURATION MANAGEMENT: 

! 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! m !!!!! j j j !!!!!!!!!!!!!!!!!!!! m !!!!!!!!!!!!!!!!!!!! j n ! 

I 

! REVISION HISTORY 

! v# , <dute>, <author iianio, description, including AR#> 

| 

I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! mmmm m Hmmm mi mmmmum 

Figure 3. Module Header Block and Revision History 

Naming conventions for subprograms, variables, and constants should be understandable (to aid traceability and 
veiiiication) and conform to requirements in the GCS specilication. The specification states specific requirements 
icgaiding the labeling ot global data stores. The specification also places a constraint on the use of variables in addition to 
the global data store variables (see the GCS specification for further information). In addition to these constraints, no 
special coding tools should be used to generate the code. Beyond those stated here, no further constraints have been 
imposed on the coding process. 


Modification 5: Modified tbe first instruction under Instructions to Programmers Regarding the Transitional Coding Phase from 

L Modify the original transition version of code such that the source code implements the detailed design description 
and conloims to the Software Coding Standards dclined above. Each programmer can reserve the original 
tiansition veisitm ol code by consulting the configuration manager using VAX Notes. Programmers can start the 
modification ol the original transition version of their code prior to the completion of the Design Reviews. 
Howevei, the code should not be icplaced in CMS or submitted for Code Review before the completion of the 
Design Review phase (since the Design Reviews can initiate changes to the design description). 

to 

I. Generate source code that implements the detailed design description and conforms to the Software Coding 
Standards defined above. ° 


Modification 6: Made minor wording changes in instructions 3 and 4 in Instructions to Programmers Regarding the 

Transitional Coding Phase. Replaced the word "Replace" with "Submit" in instruction 3; replaced the phrase 
to inlorm him that" to "when" in instruction 4; and deleted the phrase "will determine dates and times for the 
Code Reviews" from instruction 4. 
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I. Configuration item: 

Software Development Standards 


2. Date: 

3. Formal Modification #: 

5/16/94 

5 


4. Part of Configuration Item Affected: 

The following chapters uie uffected: Introduction, Softwure Requirements Stundurds, Soltwure Code Stundurds, Collecting Effort 
Data, Communication Protocol, and the Appendix b 


5. Reason for Modification: 


Change in project plan: now only have 2 implementations of the GCS application as opposed to 3 implementations. Need to chan- 
all inferences to 3 implementations and delete relerences to the Earth implementation (which is the implementation that was 


dropped). 


6. Modification: 


Modification I: Changed the reterence to three implementations to multiple implementations in several occurrences: 

(a) in section The Software Development Process for the GCS Project of the Introduction 

The GCS project involves the development of three separate implementations ... " was changed to: 
The cuirent GCS project involves the development of separate implementations ... and 
added the phrase "and only develop two of the implementations" to the end of the sentence: 

Due to the transitioning of the project from RTI to NASA along with new focus on the DO- 17813 
guidelines, the decision was made to revisit some of the original development activities. 

(b) in section Review ot the Software Requirements in Software Requirements Standards: 

In tact, the tlnee implementations ..." was changed to "In fact, the implementations ..." 

(c) in section Programming Language in Software Code Standards: 

"... thejhree GCS implementations ..." was changed to "... the GCS implementations..." 

(d) in Collecting Effort Data: 

"... tor the three GCS implementations ..." was changed to "...for the GCS implementations..." 

(e) in Instructions to the SQA Representative for Recording Effort in the Appendix,: 

"... the three GCS implementations ..." was changed to "...the GCS implementations..." in 4 places, and 
... the three implementations ..." was changed to "...the implementations..." in 1 place. 

(f) in Instiuctions to the System Analyst tor Recording Effort in the Appendix,: 

"... the three GCS implementations ..." was changed to "...the GCS implementations..." in 2 places, 
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page 2 ol' _2 

a. Report #: 5, for the Software Development Standards 

b. Notes/Explanation (Please reference appropriate section number): 

Section 6. Modification (continued): 

Modification I: (continued) 

(g) in Instructions to the Configuration Manager for Recording Effort in the Appendix,: 

... the thiee GCS implementations ... was changed to "...the GCS implementations..." in 2 places 
... all three implementations ..." was changed to "...all implementations..." in I place. 

Modification 2: Deleted references to the Earth implementation 

(a) in section Conventions for Communication between Programmers and System Analyst in Communication 
Protocol, deleted: 

SA-Eartli-Prograninier: contains all communication between the system analyst and the Earth 
Programmer 

(b) in the table labeled Efioit Hours tor Software Quality Assurance Activities in the Appendix, deleted the entire 
section referring to the Earth implementation 

(c) in the section Instructions to the Configuration Manager for Recording Effort Data in the Appendix, changed 
the phrase "Mercury, Earth, and Pluto" to "Mercury and Pluto"; and, in the table labeled Effort Hours for 

Configuration Management Activities, deleted the reterences to the Earth Programmer and Earth Verification 
Analyst 

(d) in the table labeled Effort Hours for System Analyst Activities in the Appendix, deleted the references to the 
Consulting tor the Euith implementation and Participating in Reviews tor the Earth implementation 

Modification 3: The forms shown in the Appendix for collecting effort data were originally developed using the MacDraft tool. 

Replaced the forms done in MacDralt with Word tables. Consequently, there are some minor cosmetic changes 
to the torms shown, but the content should be the same with the inclusion of the changes described above. 


F-31 



Support Documentation Change Report 


page 1 of 3 

1. Configuration Item: 

Software Development Standards 

2. Date: 
5/23/94 

3. Formal Modification #: 
6 

4. Part of Configuration Item Affected: 

The following chapters are affected: Software Requirements Standards, Software Desigi 
Reporting, Instructions for Using CMS, Communication Protocol, and the Appendix 

Standards, Problem and Change 

5. Reason for Modification: 


Originally m the project, any changes to the GCS specification were referred to as "formal modifications". Later in the project, we 
instituted a system ot Support Documentation Change Reports to handle change requests for much of the project documentation, 
including the GCS specification. The Support Documentation Change Report system was documented in the standards, but many of 
the relerences to formal modifications" were not changed. Need to change the references to the old formal modifications to make 
tliciii consistent with 1 lie Support Documentation Change Report system. 


6. Modification: 

Modification 1: in section Derived Requirements and Modification in the Software Requirements Standards, chanced the first 
paragraph from: 

In geneial, changes to the GCS specification are made through a system of "formal modifications"*. All questions raised 
by any member ot the development team regarding the GCS specification are brought to the system analyst. The system 
analyst reviews all questions and determines if changes to the specification are required. When changes are deemed 
necessary, the system analyst submits a description of the necessary modification to the SQA representative and project 
leader lor review. Figure 2 shows information that is included in the description of the modifications. The chapter 

Problem and Change Reporting" gives a more detailed description of the procedures and forms used for tracking 
reviewing and approving changes to the GCS specification." 

* f ' orn,al modifications were not issued for the changes made to the GCS specification during the transitional requirements development 
phase, since a significant number ol changes were made during one period. All changes, however, were reviewed and the revised text was 
denoted in version 2.2 as described in the previous section. All other changes to the GCS specification will be made using the system of 
formal modifications. 1 

to: 

According to DO-178B, the GCS specification is classified under control category 1 - which means that the project must 
provide a foimal system of problem reporting, change control, and change review for that data. All changes to the GCS 
specification, along with the other project support documentation, are made through a system of Support Documentation 
Change Reports. All questions raised by any member of the development team regarding the GCS specification are 
brought to the system analyst. The system analyst reviews all questions and determines if changes to the specification are 
lequired. When changes are deemed necessary, the system analyst submits a description of the necessary modification to 
the SQA representative and project leader for review. The chapter "Problem and Change Reporting" gives a more detailed 
desciiption ot the procedures and forms used for tracking, reviewing and approving changes to the GCS specification." 

Modification 2: Deleted Figure 2. Formal Modifications to the Requirements; and renumbered the figures accordingly 
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i. Report #: 6, Software Development Standards 
b. Notes/Explanation (Please reference appropriate section number): 

Section 6: (continued) 

Modification 3: Changed the term "formal modification" to "modification" in the following places: 

(a) 2 occurrences in section Derived Requirements and Modification in the Software Requirements Standards 

(b) 3 occurrences in section Problem Reporting for Support Documentation in Problem and Change Reporting 
(including changing the Support Documentation Change Report Form) 

(e) 1 occurrence in section Completing the Support Documentation Change Report in Problem and Change 
Reporting 

(d) 2 occurrences in section General Rules Regarding Topics and Replies in Communication Protocol 


Modification 4: Deleted the following sentence from section Design Documentation in Software Design Standards 

"If changes, additions, or deletions are made in response to a formal modification, the formal modification number 
should be referenced." 

Modification 5: Deleted the label "Formal Modification for Specification" from Table 2. Configuration Identification for the 
DO-178B Life Cycle Data. 

vlodification 6: Changed the following paragraph in section General Rules Regarding Topics and Replies in Communication 
Protocol from: 

"The Topic Source is either the name of the section(s) in the specification or the name of a Formal Modification to the 
specification, to which the question applies. The specification section names are predefined and appear in Table 7 
below. The programmer must use at least the first four characters of the section name if the section name has four or 
• more characters, but may use more if so desired. If the actual section name has less than four characters, then the full 
section name should be used. In those cases where the first four characters arc not unique, substitutions are given in the 
table below, and those substitutions must be used instead of the actual section name. In each case, the required part of 
the section name is bolded. If the source of the question is a Formal Modification, then the Topic Source should be 
"Modx.y-z", where x.y-z is the number of the Formal Modification. If, for some reason, none of the predefined section 
names nor a Formal Modification number is appropriate, then one should use the substitute name "other" and describe 
the source in the text part of the topic. In the case where the question applies to more than one source, list all the 
applicable sources separated by commas." 

to: 

"The Topic Source is either the name of the section(s) in the specification or the name of a modification to the 
specification, to which the question applies. The specification section names are predefined and appear in Table 7 
below. The programmer must use at least the first four characters of the section name if the section name has four or 
more characters, but may use more if so desired. If the actual section name has less than four characters, then the full 
section name should be used. In those cases where the first four characters are not unique, substitutions are given in the 
table below, and those substitutions must be used instead of the actual section name. In each case, the required part of 
the section name is bolded. If the source of the question is a Support Documentation Change Report, then the Topic 
Source should be "Modx.y-z", where x.y-z is the number of the modification. If, for some reason, none of the 
predefined section names nor a modification number is appropriate, then one should use the substitute name "other" and 
describe the source in the text part of the topic. In the case where the question applies to more than one source, list all 
the applicable sources separated by commas." 
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l. Report #: 6, Software Development Standards ~~ ~~ 

b. Noles/Explanation (Please reference appropriate section number): 

Section 6: (continued) 

Modification 7: Changed the term "Formal Modification" to "Support Documentation Change Report" in 2 occurrences in Figure 9. 

Example of Conversation Between the Programmer (PG) and System Analyst (SA) and in 1 occurrence in Figure 
10. Directory ot All Notes in the Conversation Example. 

Modification 8: In Instructions to the Programmers for Recording Effort in the Appendix, the following changes were made: 

(a) deleted the phrase: except when a change is made during this time in response to a Formal Modification to the 
specification." from instruction 2. 

(b) changed the term 'formal modification" to "modification" in instruction 3. 

(c) changed instruction 6 from 

6. Responding to Formal Modifications: record time spent reading and understanding the formal modification to the 
GCS specification and making changes to the design or code due to the formal modifications. Effort should be recorded 
in this category only after the first Design Review. 

to: 

6. Responding to Modifications to the Requirements: record time spent reading and understanding the Support 
Documentation Change Repoits lor the GCS specification and making changes to the design or code due to modifications 
to the GCS specification. Eilort should be recorded in this category only after the first Design Review. 

(d) Changed part 6. to Responding to Modifications to the Requirements in Figure 1 1. Form for Recording Effort Data 
for Programmers 

Modification 9: In Instructions to the Verification Analysts for Recording Effort in the Appendix, the following changes were 
made: 

(u) changed the litle of instruction 3 from "Responding to Formal Modifications:" to "Responding to Modifieutlous to the 
Requirements: " and made the corresponding change in Figure 12. Form for Recording Effort Data from Verification 
Analysts 

(b) changed the term formal modification" to "Support Documentation Change Report" in 2 occurrences in instruction 

3. 

(c) changed the leim toimal modification to modification" in the last occurrence in instruction 3. 

Modification 10: In Instructions to the SQA Representative for Recording Effort in the Appendix, the following changes were 
made: 

(a) changed the term formal modification to "Support Documentation Change Report" in the first paragraph and in 
instructions 2 and 3. 

(b) changed the title of instruction 5 from Reviewing Formal Modifications:" to "Reviewing Modifications to the 
Requirements: " and made the corresponding change in Figure 13. Form for Recording Effort Data from the SQA 
Representative 

Modification 11: In Instructions to the System Analyst for Recording Effort in the Appendix, changed the term "formal 
modification" to "Support Documentation Change Report" in instructions 1 and 3 
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1. Configuration Item: 

2. Date: 

3. Formal Modification #: 

Software Development Standards 

5/25/94 

7 


4. Part of Configuration Item Affected: 

Software Design Standards and Instructions to Programmers Regarding the Transitional Design Phase 


5. Reason for Modification: 

Need to revise the Software Design Standards to eliminate some items not specified by the DO-178B guidelines and not needed as 
part ot the project — in particular, the requirements to give a call structure, transition history, and revision history as part of the 
design. Also need to revise the Instructions to the Programmers Regarding the Transitional Design Phase in response to the changes 
that have been made. ° 


6. Modification: 

Modification 1: in the section Design Documentation of the Software Design Standards, deleted the sentence 

"It is important to note that the design documentation should reference the planetary name of the 
implementation, but not directly reference the name of the programmer." 

Modification 2: in the section Design Documentation of the Software Design Standards, deleted section II a) Description of 
Call Structure. Renumbered the sections accordingly. 

Modification 3: in the section Design Documentation of the Software Design Standards, added the following sentence to the start 
of section II c) Module Description: 

This section should provide the software architecture and low-level requirements, developed using the 
teaimw/A- tool, that satisfy the requirements given in the GCS specification." 

Modification 4: in the section Design Documentation of the Software Design Standards, deleted section III. Transition History. 

Modification 5 in the section Design Documentation of the Software Design Standards, deleted section IV. Revision History. 

Modification 6 in the section Design Documentation of the Software Design Standards, changed the section number for 
References from V to III. 

Modification 7: in the section Design Documentation of the Software Design Standards, deleted section VI. Appendix. 


7. 


SQA Signature & Date: 


Original Signed by 
"Kelly Hayhurst 
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Support Documentation Change Report Continuation 


. Report #: 7, Software Development Standards 


Z. HI Z, 


b. Noles/Explanation (Please reference appropriate section number): 

Section 6: (continued) 

Modification 8: in (lie Instruction to Programmers Regarding the Transitional Design Phase, changed: 

Within this transitional phase, special instructions, such as including a section describing the Transition History 
m the design documentation standards, and modifying an existing design, have been included to provide guidance 
to the project programmers due to the special circumstances of this period." 
to: 

Within this transitional phase, special instructions for modifying the existing design have been included to 
provide guidance to the project programmers due to the special circumstances of this period." 

Modification 9: in the Instructions to Programmers Regarding the Transitional Design Phase, changed: 

"1. Modifying the original design of their implementation (developed at RTI) so that the new detailed design 
meets the requirements ol version 2.2 ot the GCS specification and the standards set forth in this document in the 
chapter Software Design Standards". As described in the design standards, the CASE tool, teami vork should be 
used to update the design to refleet the functionality in version 2.2 of the specification prior to making 
modifications to the code. ‘ 

to: 

"1. Modifying the original design of their implementation (developed at RTI) so that the new detailed design 
meets the requirements ot the most current version of the GCS specification and the standards set forth in this 
ocumuit in the chapter Software Design Standards". As described in the design standards, the CASE tool 
team it'd/ A', should be used to update the design." 

Modification 10: m item 4. of the Instructions to Programmers Regarding the Transitional Design Phase, changed the references 
to the SQA representative to the project leader. 

Modification II: in item 4. of the Instructions to Programmers Regarding the Transitional Design Phase, changed the phrase: 

will determine dates and times tor the Design Reviews and contact the participants in the review to schedule the 
review sessions. 

to: 

will contact the participants in the review to schedule the review sessions." 
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Support Documentation Change Report 


page 1 of 1 

1 . Configuration Item: 

Software Development Standards 

2. Date: 
5/25/94 

3. Formal Modification #: 
8 


4. Part of Configuration Item Affected: 
Software Requirements Standards 


5. Reason for Modification: 


The paragraph at the end of the section Review of the Software Requirements discusses the bolding used to highlight changes when 
we went to version 2.2 of the specification. Since we have since revised the specification and removed the bolding, this paragraph is 
no longer appropriate. 


6. Modification 

Deleted the following paragraph from the end of the section Review of the Software Requirements in the Software Requirements 
Standards: 

Version 2.2 of the GCS specification contains a number of modifications to version 2.1 of the specification document. To help 
identify changes made during the enhancement of the specification, the text that was modified from version 2.1 was bolded in 
version 2.2. Some existing text was moved to another place in the document, and some text was deleted. There is no demarcation 
in version 2.2 to indicate where text was moved or deleted. The modifications that are significant (may impact the coding of an 
implementation) are marked with a footnote number. Where there were a number of significant modifications within a processing 
step (in Level 3 of the specification), a footnote number was placed just at the top of the processing step (as opposed to marking 
each individual change within the processing step). There was also a significant new addition to the specification: requirements 
for exception handling. New additions to the text were also bolded. 


7, SQA Signature & Date: 


Original Signed by 
Kelly Hayhurst 
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Support Documentation Change Report 


page I of I 


1 . Configuration Item: 

2. Date: 

r — ' — 

3. Formal Modification #: 

Software Development Standards 

5/25/94 

9 

4. Part of Configuration Item Affeeted: 



Instructions for Using CMS and the Appendix 




5. Reason for Modification: 


In SDCR #4, changed the project plan to have the programmers generate their own source code for the implementation instead of 
modifying existing code for the implementation developed at the Research Triangle Institute. However, some text in the 
Instructions for Using CMS and the Appendix still contains language about using the old code from RTI and needs to be corrected. 


6. Modification 


Modification I: Deleted the last paragraph, shown below, in the section Basic CMS Commands in the chapter Instructions for 
Using CMS: 

Prior to the first code review, a programmer can reserve a copy of the original transition version of code and make 
changes so that the source code implements the design description and conforms to the Software Coding 
Standards. While the specific element generations making up the original transition code are reserved, the 
programmers are allowed to make as many changes as needed without replacing the element after each change. 
Howevei, once the code has been submitted lor Code Review, changes to the code can be made only in response 
to a Pioblcm Report. In addition, the source code element should be reserved and replaced with each individual 
change. The Action report lor each change should be noted in the comment for that reservation. 


Modification 2: Added the sentence below to the new last paragraph in the section Basic CMS Commands in the chapter 
Instructions for Using CMS 

The report number for each change should be noted in the comment for that reservation." 


trom: 


Modification 3. in the Instructions to the Programmers for Recording Eflort in the Appendix, changed instruction 2 fi 

2. Changing Code during Transitional Coding Phase: record time spent updating the existing software code to 
match the detailed design description. This will include all time spent modifying the code until the time of the 


first Code Review, 
to 


2. Developing Source Code: record time spent developing source code to meet the detailed design description. 
This will include all time spent generating the source code until the time of the first Code Review." 


7. SQA Signature & Date: 


Original Signed by 
Kelly Hayhurst 
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Support Documentation Change Report Continuation 


page 2 of _2 

а. Report #: 9, for the Software Development Standards 

б. Modification 

Section 6: (continued) 

Modification 4. in the Instructions to the Programmers for Recording Effort in the Appendix, changed the label for instruction 2 
in Figure 1 1 . Form for Recording Effort Data from Programmers to "2. Developing Source Code" 

Modification 5: in the Instructions to the Verification Analysts for Recording Effort Data in the Appendix, changed the phrase 
"Transitional Coding Phase" to "Coding Phase" in 3 occurrences in Figure 12. Form for Recording Effort Data 
from Verification Analysts 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-1 

Date: December 30, 1992 

Part of Specification Affected: 

Chapter 5 
AECLP 

Page 38 

Section labeled "PROCESSING WHEN AXIAL ENGINES ARE ON" 

Last sentence of the first paragraph 

Reason for Modification: 

The statement pertaining to the initialization of PEJNTEGRAL, YEJNTEGRAL, and TEJNTEGRAL 
needs to be corrected. If the trajectory begins with FRAME_COUNTER set to one, then these 
variables will be initialized to zero; however, if the FRAME_COUNTER begins at a value other than 
one, these variables may be initialized to a value other than zero. 


Modification: 

Original Text: 

"The variables PEJNTEGRAL, YEJNTEGRAL, AND TEJNTEGRAL will be Initialized to the 
value zero by INIT_GCS." 

Action: 

• Delete the text "to the value zero" 

Modified Text: 

"The variables PEJNTEGRAL, YEJNTEGRAL, AND TE INTEGRAL will be Initialized by 
INIT GCS." 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-2 

Date: December 30, 1992 

Part of Specification Affected: 

Chapter 5 
RECLP 

Page 65 

Section labeled "DETERMINE PULSE INTENSITY AND DIRECTION” 

Third sentence from the end of the paragraph 

Reason for Modification: 

The statement pertaining to the initialization of the variable THETA needs to be corrected. The 
variable THETA will be initialized to the initial roll angle which is not necessarily zero. 


Modification: 

Original Text: 

"The variable THETA will be Initialized to the value zero by INIT_GCS." 
Action: 

• Delete the text "to the value zero" 

Modified Text: 

"The variable THETA will be initialized by INIT_GCS." 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-3 

Date: December 30, 1992 


Part of Specification Affected: 

Chapter 5 
AECLP 
Page 41 

Section labeled "COMPUTE AXIAL ENGINE VALVE SETTINGS" 
Last sentence in the section 

Reason for Modification: 

The wording "to the nearest integer" needs more specificity. 


Modification: 

Original Text: 

"with INTERNAL_CMD between 0 and 1.0 being converted linearly ( to the nearest Integer) 27 
to a value of AE_CMD between 0 and 127." 

Actions: 

• Delete the text " (to the nearest Integer) 27 ” 

Add new text which will then become the last sentence in the section. The new sentence is 
shown below under "Text to be Added". 

Text to be Added: 

"Each value for AE_CMD is to be rounded to the nearest integer, where rounding is 
defined as follows: 27 

Let x represent the real value that is to be rounded 
Then, AE_CMD = the Integer part of (x + 0.5)" 

Modified Text: 

"with INTERNAL_CMD between 0 and 1.0 being converted linearly to a value of AE_CMD 
between 0 and 127. Each value for AE_CMD Is to be rounded to the nearest integer, where 
rounding is defined as follows: 27 
Let x represent the real value that is to be rounded 
Then, AE_CMD = the Integer part of (x + 0.5)" 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-4 


Dale: February 8, 1993 

Part of Specification Affected: 

Chapter 5 
GP 

Page 60 
Table 5.10 

First line of the table (GP_PHASE = 1 ), under the column labeled "EVENT" 


Reason for Modification: 

The phrase "and engines were not turned off In prior frame" is unecessary because when the 
lander is in Phase 1 , the engines will not yet have been turned off. 


Modification: 

Original Text: 

"Altitude for turning engines on is sensed and engines were not turned off In prior frame" 
Action: 

• Delete the text "and engines were not turned off In prior frame" 

Modified Text: 

"Altitude for turning engines on is sensed" 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-5 

Date: February 24, 1993 

Part of Specification Affected: 

Chapter 5 
ARSP 

Page 43 

INPUT (list of variables that are inputs to this processing module) 
Reason for Modification: 

The variable FRAME_COUNTER was omitted from the list of inputs. 


Modification: 
Original Text: 
INPUT 


AR_ALTITUDE 

AR_COUNTER 

AR_FREQUENCY 

K_ALT 

AR_STATUS 


Action: 

• Add the variable FRAME_COUNTER to the list of inputs. 


Modified Text: 
INPUT 


AR_ALTITUDE 

AR_COUNTER 

AR_FREQUENCY 

AR_STATUS 

FRAME_COUNTER 

K_ALT 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-6 


Date: March 10, 1993 

Part of Specification Affected: 

Chapter 6, Data Requirements Dictionary 
PART I. DATA ELEMENT DESCRIPTIONS 
Page 89 (GVE) 

Page 91 (PE_MAX and PE_MIN) 

Page 94 (TE_MAX and TE_MIN) 

Page 95 (YE_MAX and YE_MIN) 

Reason for Modification: 

The DATA TYPE for GVE should be "real*8" instead of "array(1 ..2) of real‘8". 

The DATA TYPE for PE_MAX, PE_MIN, TE_MAX, TE_MIN, YE_MAX, and YE_MIN should be 
"array(1..2) of real*8" rather than "real‘8" 


Modification for GVE: 

Original Text: 

DATA TYPE: array(1 ..2) of real*8 
Action: 

• Delete "array(1 ..2) of” before "rears" 

Modified Text: 

DATA TYPE: real*8 


Modification for PE_MAX, PE_MIN, TE_MAX, TE_MIN, YE_MAX and YE_MIN: 
Original Text: 

DATA TYPE: real‘8 
Action: 

• Insert "array(1 ..2) of" before "rears" 

Modified Text: 

DATA TYPE: array(1 ..2) of real*8 


F-46 



Software Requirements GCS Development Specification 

Formal Modification # 2.2-7 

Date: March 10, 1993 

Part of Specification Affected: 

Chapter 5 
AECLP 

Page 38, Section labeled "COMPUTE LIMITING ERRORS FOR PITCH" 

Page 39, Section labeled "COMPUTE LIMITING ERRORS FOR YAW" 

Page 39, Section labeled "COMPUTE LIMITING ERRORS FOR THRUST" 

Reason for Modifications: 

The variable GVE is a scalar, and thus references to it should not be subscripted. 

Each of the variables PE_MIN, PE_MAX, TE_MIN, TE_MAX, YE_MIN, and YE_MAX is an array 
with two elements, and thus references to individual elements mus be subscripted. 

Modification: 

Original Text: 

COMPUTE LIMITING ERRORS FOR PITCH 

•• If P e L < PE_MIN then set P e L to PE_MIN. 

•• If P e L > PE_MAX then set P e L to PE_MAX. 

COMPUTE LIMITING ERRORS FOR YAW 

•• If Y e L < YE_MIN then set Y e L to YE_MIN. 

•• If Y e L > YE_MAX then set Y e L to YE_MAX. 

COMPUTE LIMITING ERRORS FOR THRUST 

GVE(CL)*VELOCITY_ERROR + GVEI(CL)-TE_INTEGRAL 
••• If TE_LIMIT < TE_MIN then set TE_LIMIT to TE_MIN. 

— If TE_LIMIT > TE_MAX then set TE_LIMIT to TE MAX. 


Actions 

• Replace occurrence of GVE(CL) with GVE. 

• Replace occurrences of PE_MIN, PE_MAX, TE_MIN, TE_MAX, YE_MIN, YE_MAX with 
PE_MIN(CL), PE_MAX(CL), TE_MIN(CL), TE_MAX(CL), YE_MIN(CL), YE_MAX(CL), 
respectively. 
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Modified Text: 

COMPUTE LIMITING ERRORS FOR PITCH 

•• If P 0 L < PE_MIN(CL) then set P 0 L to PE_MIN(CL). 

•• If P e L > PE_MAX(CL) then set P e L to PE_MAX(CL). 

COMPUTE LIMITING ERRORS FOR YAW 

•• If Y e L < YE_MIN(CL) then set Y e L tO YE_MIN(CL). 

•• If Y e L > YE_MAX(CL) then set Y e L to YE_MAX(CL). 

COMPUTE LIMITING ERRORS FOR THRUST 

GVE-VELOCITY_ERROR + GVEI(CL)*TE_INTEGRAL 
“ TE_LIMIT < TE_MIN(CL) then set TE_LIMIT to TE_MIN(CL). 

•• If TE_LIMIT > TE_MAX(CL) then set TE_LIMIT to TE_MAX(CL). 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-8 

Date: March 10, 1993 

Part of Specification Affected: 

Chapter 5 
GP 

Page 61, Section labeled "DETERMINE WHICH SET OF CONTROL LAW PARAMETERS TO 
USE" 

Reason for Modifications: 

The subset of variables listed in the first paragraph should not contain the variable GVE and is 
missing the variables PE_MIN, PE_MAX, TE_MIN, TE_MAX, YE_MIN, and YE_MAX. 

Modification: 

Original Text: 

...This subset consists of the following eight variables: GVE, GVEI, G V, GVI, GR, GW, GWI, and 
GQ. Note that each one of these variables is an array of two elements. The eight elements with 
a subscript of one will be referred to as the "first" set of Control Law Parameters, while the eight 
elements with... 

Actions 

• Remove the variable GVE from the list 

• Add the variables PE_MIN, PE_MAX, TE_MIN, TE_MAX, YE_MIN, and YE_MAX to the list. 

• Remove all references to "eight” variables 


Modified Test: 

...This subset consists of the following variables: GVEI, GV, GVI, GR, GW, GWI, GQ, PE_MIN, 
PE_MAX, TE_MIN, TE_MAX, YE_MIN, and YE_MAX. Note that each one of these variables is an 
array of two elements. The elements with a subscript of one will bo referred to as the "first” set of 
Control Law Parameters, while the elements with ... 
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Software Requirements GCS Development Specification 
Formal Modification #2.2-9 


Date: May 20, 1993 

Part of Specification Affected: 

INTRODUCTION 


Location: 

Page 13, section labeled DEFINITIONS, immediately before the definition for Global Data Store 
Variable". 

Reason for Modification: 

To define the use in this specification of the term "data store". 

Action: 

Insert definition for "data store" 

New Text: 

Data Store 

The definition for a data or control store given in Hatley[13] is "A data or control store is simply a 
data or control flow frozen in time. The data or control information it contains may be used any time 
after that information is stored and in any order.” In this specification, all stores contain data, while 
some also contain data conditions. For the purposes of this specification, the term "data store" will 
be used to refer to any store which contains some combination of data and data conditions. Thus, 
all four stores listed in the Data Requirements Dictionary part II will be referred to as "data stores". 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-10 

Date: May 27, 1993 

Parts of Specification Affected: 

Chapter 2, LEVEL 0 SPECIFICATiON 
Chapter 3, LEVEL 1 SPECJFiCATION 


2 . 2 - 10.1 

Location: 

Page 19 

Reason for Modification: 

In order to accurately reflect the new contents of Chapter 2 
Action: 

Change the title. 

Original Text 

2. LEVEL 0 SPECIFICATION 
Modified Text 

2. LEVELS 0 and 1 SPECIFICATION 


2 . 2 - 10.2 


Location: 

Page 21, second sentence 
Reason for Modification: 

To improve the wording. 
Action: 


Change the text "impact upon landing" to "touch down" 

Original Text: 

The purpose of the GCS is to keep the vehicle descending along the predetermined velocity-altitude 
landing Wh ' Ch ^ Chosen ,0 conserve enough fuel to effect a safe attitude and impact upon 
Modified Text: 

J^ntfMru?h S ^h 0f h the K GCS t0 keep the vehicle descendin 9 along the predetermined velocity-altitude 
contour which has been chosen to conserve enough fuel to effect a safe attitude and touch down. 


2.2-10.3 

Location: 

Page 21, last sentence in next-to-last paragraph. 

Reason for Modification: 

An expfanahon regarding the structured analysis diagrams has been added as the last paragraph in 
this section, and is not needed here. H y C,H " 

Action: 

Delete the entire sentence. 

Original Text: 

The figures in Chapters 2-4 follow the Structured Analysis/Structured Design notation (see 
Appendix A). ax 

Modified Text: 

(none) 


2.2-10.4 

Location 

Page 21, immediately before last sentence in last paragraph 
Reason for Modification: 

A sentence was omitted. 

Action: 
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Insert a new sentence "In addition, FORTRAN Intrinsic Functions may be used." between the two 
sentences in the original text. 

Original Text: 

"...in Appendix B. Other system services...” 

Modified Text: 

"...in Appendix B. In addition, FORTRAN Intrinsic Functions may be used. Other system 
services..." 


2.2-10.5 

Location: 

Page 21, following last paragraph, and all of page 22. 

Reason for Modification: 

An explanation is required for the differences between the structured analysis diagrams in this 
specification and those in Hatley[13]. 

Action: 

Insert new text after the last paragraph. Because the additional text does not all fit on page 21 , the 
overtlow has replaced page 22, and the new Figure 2.1 appears on page 23. 

Original Text: 

Other system services and library routines are explicitly excluded from use by the programmer. 
Modified Text: 

Other system services and library routines are explicitly excluded from use by the programmer. 

Figures 2.2 through 2.5, 3.1, 3.2, and 4.1 through 4.4, and Tables 2.1, 3.1, 4.1, and 4.2 follow 
Hatley's extension to Structured Analysis (see Appendix A), with the following exceptions and 
assumptions. 

Exceptions: 

1 . Any data store may appear at more than one level because the processes specified do not 
communicate directly but only through data stores. 

2. Any unlabeled flow between a process and a data store may not necessarily carry all the 
information in the data store (the actual flow content is defined by the process specification 
and the Data Requirements Dictionary Part II). 

Assumptions: 

1 . The initial value for control signals is assumed to be "FALSE". 

2. In a process activation table (PAT), an empty process cell indicates the process is 
deactivated. 

3. In a PAT, an empty output cell indicates the control signal value remains unchanged. 

4. In a PAT, output control signals receive values before any processes are activated and 
therefore may delay the activation of processes by deactivating their parent process. 

An example of assumption 4 is Table 3.1 where setting RENDEZVOUS to "TRUE" delays the 
activation of the processes of which RUN_GCS Is composed until GCS_SIM sets RENDEZVOUS 
to "FALSE". 


2 . 2 - 10.6 

Location: 

Page 23, entire page 
Reason for Modification: 

An additional figure showing the structure of the GCS specification is needed. 
Action: 

The old Figure 2.2 was replaced with an entirely new Figure 2.1. 


2.2-10.7 

Location: 

Page 24, entire page 

Reason for Modification: 

The old structured analysis diagrams are being replaced by new ones. 
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Action: 

A blank page was replaced with an entirely new structured analysis Figure 2.2. 


2 . 2 - 10.8 

Location: 

Page 25, entire page 
Reason for Modification: 

The old structured analysis diagrams are being replaced by new ones. 

Action: 

The old Chapter 3 title was replaced with an entirely new structured analysis Figure 2.3. 


2.2-10.9 

Location: 

Page 26, entire page 
Reason for Modification: 

The old structured analysis diagrams are being replaced by new ones. 

Action: 

A blank page was replaced with a Chapter 3 subtitle and an entirely new structured analysis 
Figure 2.4. 


2 . 2 - 10.10 

Location: 

Page 27 

Reason for Modification: 

The old structured analysis diagrams are being replaced by new ones. 

Action: 

The old Figure 3.1 and the chapter subtitle were replaced with an entirely new structured analysis 
Figure 2.5. 


2 . 2 - 10.11 

Location: 

Page 28 

Reason for Modification: 

The old structured analysis diagrams are being replaced by new ones. 

Action: 

The old Figure 3.2 and Table 3.1 were replaced with an entirely new structured analysis Table 2.1 . 
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Software Requirements GCS Development Specification 
Formal Modification # 2.2-11 


Date: June 2, 1993 

Parts of Specification Affected: 

Chapter 4, LEVEL 2 SPECIFICATION 

Modification 2.2-11.1 
Location: 

Page 29, chapter number 
Reason for Modification: 

The old Chapter 4 now becomes the new Chapter 3. 

Action: 

Change the chapter number. 

Original Text 

4. LEVEL 2 SPECIFICATION 
Modified Text 

3. LEVEL 2 SPECIFICATION 

Modification 2.2-11.2 
Location: 

Page 31, section title on second line 
Reason for Modification: 

In order to reflect the new structured analysis diagrams. 

Action: 

Replace the section title. 

Original Text: 

PROCESS 1. INIT_GCS 18 
Modified Text: 

PROCESS SPECIFICATION (P-Spec) 1: INIT_GCS 18 

Modification 2.2-11.3 
Location: 

Page 31 , INPUT and OUTPUT sections 
Reason for Modification: 

The input is incorrect, and the output can be stated directly rather than using a reference to a table. 
Action: 

Replace both the INPUT and OUTPUT sections. 

Original Text: 

INPUT 



Modified Text: 
INPUT 


INITIALIZATION_DATA 
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OUTPUT 


INITIALIZATIONLDATA 


Modification 2.2-11.4 
Location: 

Page 31, Subsection labeled "PROCESS", beginning with the first paragraph, last sentence, and 
continuing through to the end of the page. 

Reason for Modification: 

A new variable SUBFRAME_COUNTER is being added to the EXTERNAL data store for use by the 
functional unit CP. Also, the fact that FRAME_COUNTER and SUBFRAME_COUNTER are 
actually included in INITIALIZATION_DATA needs clarification. 

Action: 

Text has been reworded and reorganized to explain the initialization process and to specifically 
explain the initialization of the two variables FRAME_COUNTER and SUBFRAME_COUNTER. 
Original Text: 

The first call to GCS_SIM_RENDEZVOUS will cause INIT_GCS to automatically be executed, 
which will result In the loading of all necessary Initial values and the initialization of the 
frame counter (FRAME_COUNTER) as follows: 

LOAD INITIAL VALUES 

• Load Initial values for all variables listed In part III of the Data Requirements Dictionary, 
namely Table 6.7, Initialization Data. 

SET FRAME COUNTER 

• FRAME_COUNTER will be initialized to some number representing the next frame to be 
executed. This allows the option of starting execution at some point beyond the first frame of 
a trajectory. 

Modified Text: 

The first call to GCS_SIM_RENDEZVOUS will cause INIT_GCS to automatically be 
executed. INIT_GCS will initialize all variables in the group flow INITIALIZATION_DATA, 
which is defined in Table 6.7 in the Data Requirements Dictionary Part III. Since the 
variables FRAME_COUNTER and SUBFRAME_COUNTER are part of 
INITIALIZATION_DATA, they will be initialized at this time. FRAME_COUNTER will be 
initialized to a value representing the next frame to be executed, while 
SUBFRAME_COUNTER will always be initialized to the value one, which implies that the first 
subframe of the first frame to be executed will always be the sensor processing subframe. 
Although a terminal descent trajectory begins with FRAME_COUNTER initialized to the value 
one, the option exists for starting execution at some point other than at the beginning of the 
trajectory, i.e., FRAME_COUNTER may be initialized to a value greater than one. 

Modification 2.2-11.5 
Location: 

Between pages 31 and 32 
Reason for Modification: 

Additional structured analysis figures and tables and one new chapter heading page were needed. 
Action: 

New pages 31.1 through and including page 31.9 have been added containing additional structured 
analysis diagrams (Figures 3.1, 3.2, 4.1, 4.2, 4.3, and Tables 3.1, 4.1) as well as one new chapter 
heading for Chapter 4 (page 31 .4). 

Modification 2.2-11.6 
Location: 

Page 32, entire page 
Reason for Modification: 

The old structured analysis diagrams are being replaced by new ones. 

Action: 
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The old Figure 4.1 was replaced with an entirely new structured analysis Figure 4.4. 

Modification 2.2-11.7 
Location: 

Page 33, entire page 
Reason for Modification: 

The old structured analysis diagrams are being replaced by new ones. 

Action: 

The old Figure 4.2 was replaced with an entirely new structured analysis Table 4.2. 

Modification 2.2-11.8 
Location: 

Page 34, Section labeled "SCHEDULING", sixth sentence 
Reason for Modification: 

Clarification. 

Action: 

Add the text " (frame number 1)" 

Original Text: 

Also note that execution of the GCS may begin at any frame number and should operate as if it had 
been running from the beginning of the trajectory. 

Modified Text: 

Also note that execution of the GCS may begin at any frame number and should operate as if it had 
been running from the beginning of the trajectory (frame number 1 ). 

Modification 2.2-11.9 
Location: 

Page 34, Section labeled "SCHEDULING, third sentence from end of paragraph. 

Reason for Modification: 

A new variable SUBFRAME_COUNTER is being added, and thus text describing the initialization 
and updating of the value of SUBFRAME_COUNTER needs to be included. 

Action: 

Add the text " and SUBFRAME_COUNTER". 

Original Text: 

On the first, and subsequent, calls to GCS_SIM_RENDEZVOUS, FRAME_COUNTER 
will be returned to the implementation containing the correct value for operation. 

. Modified Text: 

On the first, and subsequent, calls to GCS_SIM_RENDEZVOUS, FRAME_COUNTER and 
SUBFRAME_COUNTER will be returned to the Implementation containing the correct values for 
operation. 

Modification 2.2-11.10 
Location: 

Page 34, Section labeled "SCHEDULING", second and next-to-last sentences 
Reason for Modification: 

Table 4.1 was renumbered to 4.3 because new tables were added before it. 

Action: 

Change the number of the table from 4.1 to 4.3. 

Original Text: 

"...Table 4.1..." 

Action: 

Change the number of the table. 

Modified Text: 

"...Table 4.3..." 


Modification 2.2-11.11 
Location: 

Page 34, heading for table 
Reason for Modification: 
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Table 4.1 was renumbered to 4.3 because new tables were added before it. 

Action: 

Change the number of the table. 

Original Text: 

Table 4.1: FUNCTIONAL UNIT SCHEDULING 21 
Modified Text: 

Table 4.3: FUNCTIONAL UNIT SCHEDULING 21 

Modification 2.2-11.12 
Location: 

Page 34, footnote at bottom of page 

Reason for Modification: 

Chapter 5 now contains functional unit descriptions for both levels 3 and 4, rather than just level 3. 
Action: 

Delete reference to levels, and merely refer to the chapter. 

Original Text: 

"...In the Level 3 Specification, Chapter 5." 

Modified Text: 

"...In Chapter 5." 

Modification 2.2-11.13 
Location: 

Between pages 34 and 35 
Reasons for Modification: 

The specification needs clarification regarding the requirement to execute sequential frames. Also, 
the criteria and procedures for terminating GCS had been given in the functional unit GP, but are 
more appropriate in the scheduling section. 

Action: 

Insert new page, namely page 34.1, with new text to describe the sequential execution of frames 
and also the reworded termination criteria and procedures for GCS. 

New Text: 

The GCS software must meet all the requirements for a particular frame for any specific value of 
the variable FRAME_COUNTER. The software must be capable of executing continuously one 
frame after another until specified termination conditions are met, at which time it must terminate 
itself according to specified termination procedures. 

The termination conditions and procedures are: GCS should check whether to terminate Itself in 
each frame immediately after executing the Guidance Processing functional unit. At that time if the 
value of the variable GP_PHASE is equal to 5, then GCS should terminate itself gracefully (without 
any exception conditions). In this case, the implementation should terminate at the end of the 
present subframe, i.e., it should execute the functional unit Communications Processing and then 
terminate without calling GCS_SIM_RENDEZVOUS. 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-12 

Date: June 2, 1993 

Parts of Specification Affected 
FOREWORD 
Contents 
List of Figures 
List of Tables 
Chapter 1, INTRODUCTION 
Chapter 5, LEVEL 3 SPECIFICATION 

General Reason for Modifications: 

To bring the specification into agreement with the new structured analysis diagrams. 

2 . 2 - 12.1 

Location: 

Page iii, second paragraph, sixth sentence 
Reason for Modification: 

The P-Specs for the functional units are now at both level 3 and level 4 
Action: 

Change the reference. 

Original Text: 

"...(in level 3 of the specification)..." 

Modified Text: 

"...(in Chapter 5 of the specification)..." 


2 . 2 - 12.2 

Location: 

Page vi 

Reasons for Modifications: 

The old structured analysis diagrams are being replaced by new ones in which an additional level 
was added to the structured diagrams, namely that for specifying the three subframes. 

Actions: 

The old Chapters 2 and 3 have now both been incorporated into Chapter 2 which now contains the 
specifications for levels 0 and 1 instead of just level 0. 


The old Chapter 4 has become the new Chapter 3 which now contains the level 2 specification 
instead of the level 1 specification. 


A new Chapter 4 has been included which now contains the level 3 flow diaqrams and C-SDecs 
instead of the level 2 specification. H 

The names for Chapters 2, 3, 4, and 5 were changed, and section headings were added for 
Chapters 2 and 3 and changed for Chapter 5. 

The names for the section headings in Chapter 5 were changed. 

Chapter 5 now contains the levels 3 and 4 P-Specs instead of just the level 3 specification. 

The title for Chapter 6, Part III was changed in order to be a more accurate representation of the 


The title for Appendix A was changed to include the new level. 
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2.2- 12.3 
Location: 

Page vii 

The titles for Figures 2.1 , 2.2, 3.1 , 3.2, 4.1 , and 4.2 were changed, and entries for Figures 2.3, 
2.4. 2.5, 4.3, and 4.4 were added in order to incorporate the new structured analysis diagrams. 

2.2- 12.4 
Location: 

Page ix 

The titles for Tables 3.1 and 4.1 were changed. Entries for Tables 2.1 , 4.2, 4.3 and Tables 6.8 
through 6.12 were added in order to incorporate the new structured analysis diagrams. 


2.2-12.5 

Location: 

Page 12, Subsection labeled "Functional Unit", first sentence 
Reason for Modification: 

The P-Specs for the functional units are now at both levels 3 and level 4 
Action: 

Change the reference. 

Original Text 

"Chapter 5 (LEVEL 3 SPECIFICATION) is divided..." 

Modified Text 

"Chapter 5 Is divided..." 


2 . 2 - 12.6 

Location: 

Page 14, Subsection labeled "Order of Processing", first sentence 
Reason for Modification: 

The P-Specs for the functional units are now at both levels 3 and level 4 
Action: 

Change the reference. 

Original Text 

"...in the Level 3 specification,..." 

Modified Text 

"...in Chapter 5,..." 


Location: 

Page 15, Subsection labeled "Rotation of History Variables", first sentence. 
Reason for Modification: 

The P-Specs for the functional units are now at both levels 3 and level 4 
Action: 

Change the reference. 

Original Text 

"In the LEVEL 3 SPECIFICATION,..." 

Modified Text 
"In Chapter 5,..." 


2 . 2 - 12.8 

Location: 

Page 35 

Reason for Modification: 

The P-Specs for the functional units are now at both level 3 and level 4 
Action: 

Replace the chapter title. 

Original Text: 

5. LEVEL 3 SPECIFICATION 
Modified Text: 

5. P-Specs FOR LEVELS 3 AND 4 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-13 

Date: June 2, 1993 

Part of Specification Affected: 

Chapter 5 
AECLP 


2.2-13.1 

Location: 

Page 37, title for P-Spec. 

Reason for Modification: 

In order to reflect the numbering in the new structured analysis charts 
Action: 

Replace the title. 

Original Text: 

2.1 AECLP - Axial Engine Control Law Processing 
Modified Text: a 

AECLP - Axial Engine Control Law Processing (P-Spec 2.3.1) 


2.2-13.2 

Location: 

Page 37, INPUT (list of variables that are inputs to this functional unit) 

Reasons for Modification: 

The variables GP_ATTITUDE and GRAVITY were omitted from the list of inputs. 
The variable AE_STATUS should not have been included in the list of inputs. 
The input variables are not listed in ascii sequence 
Actions: 


Add the variables GP_ATTITUDE and GRAVITY to the list of inputs 
Delete the variable AE STATUS from the list of inputs. 

Rearrange the modified list of inputs in ascii sequence. 
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Original Text: 
INPUT 


A_ACCELERATION 

AE_STATUS 

AE_SWITCH 

AE_TEMP 

CHUTE_RELEASED 

CL 

DELTA_T 

FRAME_COUNTER 

FRAME_ENGINES_IGNITED 

FULI — UP TIME 

CONTOUR_CROSSED 

ENGINES_ON_ALTITUDE 

GA 

GAX 

GP_ALTITUDE 

GP_ROTATION 

GP_VELOCITY 

GP1 

GP2 

GPY 

GQ 

GR 

GV 

GVE 

GVEI 

GVI 

GW 

GWI 

OMEGA 

PEJNTEGRAL 

PE_MAX 

PE_MIN 

TE_INTEGRAL 

TE INIT 

TE_LIMIT 

TE_MAX 

TE_MIN 

TE_DROP 

VELOCITY_ERROR 

YE_INTEGRAL 

YE_MAX 

YE_MIN 


Modified Text: 
INPUT 


AE_SWITCH 

AE_TEMP 

A_ACCELERATION 

CHUTE_RELEASED 

CL 

CONT OUR_CROSSED 

DELTA_T 

ENGINES_ON_ALTITUDE 

FRAME_COUNTER 

FRAME_ENGINES IGNITED 

FULL_UP_TIME 

GA 

GAX 

GP1 

GP2 

GPY 

GP_ALTITUDE 

GP_ATTITUDE 

GP_ROTATION 

GP_VELOCITY 

GQ 

GR 

GRAVITY 

GV 

GVE 

GVEI 

GVI 

GW 

GWI 

OMEGA 

PEJNTEGRAL 

PE_MAX 

PE_MIN 

TE_DROP 

TEJNIT 

TEJNTEGRAL 

TE_LIMIT 

TE_MAX 

TE_MIN 

VELOCITY_ERROR 

YEJNTEGRAL 

YE_MIN 

YE_MAX 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-14 

Date: June 2, 1993 


Part of Specification Affected: 
Chapter 5 
GSP 


2.2-14.1 

Location: 

Page 63, title for P-Spec. 

Reason for Modification: 

In order to reflect the numbering in the new structured analysis figures. 
Action: 

Replace the title. 

Original Text: 

2.7 GSP - Gyroscope Sensor Processing 
Modified Text: 

GSP - Gyroscope Sensor Processing (P-Spec 2.1.4) 


2.2-14.2 

Location: 

Page 63, INPUT (list of variables that are inputs to this functional unit) 
Reason for Modification: 

The variable G_STATUS should not have been included in the list of inputs. 
Action: 

Delete the variable G_STATUS from the list of inputs. 

Original Text: 

INPUT 


ATMOSPHERIC_TEMP 

G3 

G4 

G_COUNTER 

G_GAIN_0 

G_OFFSET 

G_ROTATION 

G_STATUS 


Modified Text: 
INPUT 


ATMOSPHERIC_TEMP 

G3 

G4 

G_COUNTER 

G_GAIN_0 

G_OFFSET 

G_ROTATION 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-15 


Date: June 2, 1993 

Part of Specification Affected: 
Chapter 5 
RECLP 


2.2-15.1 

Location: 

Page 65 (with mod 2.2-2), title for P-Spec. 

Reason for Modification: 

In order to reflect the numbering in the new structured analysis figures. 
Action: 

Replace the title. 

Original Text: 

2.8 RECLP - Roll Engine Control Law Processing 
Modified Text: 

RECLP - Roll Engine Control Law Processing (P-Spec 2.3.2) 


2.2-15.2 

Location: 

Page 65, INPUT (list of variables that are inputs to this functional unit) 
Reason for Modification: 

The variable RE_STATUS should not have been included in the list of inputs. 
Action: 

Delete the variable RE_STATUS from the list of inputs. 

Original Text: 

INPUT 


DELTA_T 

G_ROTATION 

PI 

P2 

P3 

P4 

RE_STATUS 

RE.SWITCH 

THETA 

THETA! 

THETA2 



Modified Text: 
INPUT 


DELTA_T 

G_ROTATION 

PI 

P2 

P3 

P4 

RE_S WITCH 

THETA 

THETA! 

THETA2 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-16 


Date: June 2, 1993 


Part of Specification Affected: 
Chapter 5 
TDLRSP 


2.2-16.1 

Location: 

Page 67, title for P-Spec. 

Reason for 2.2-16.: 

In order to reflect the numbering in the new structured analysis figures. 
Action: 

Replace the title. 

Original Text: 

2.9 TDLRSP - Touch Down Landing Radar Sensor Processing 
Modified Text: 

TDLRSP - Touch Down Landing Radar Sensor Processing (P-Spec 2.1.3) 


Location: 

Page 67, INPUT (list of variables that are inputs to this functional unit) 
Reason for 2.2-16.: 

The variable TDLR_STATUS should not have included in the list of inputs. 
Action: 

Delete the variable TDLR_STATUS from the list of inputs. 

Original Text: 

INPUT 


DELTA_T 

FRAME_BEAM_UNLOCKED 

FRAME_COUNTER 

K_MATRIX 1 

TDLR_ANGLES 

TDLR_COUNTER 

TDLR_GAIN 

TDLR_LOCK_TIME 

TDLR_OFFSET 

TDLR_STATE 1 

TDLR_STATUS 

TDLR_VELOCITY 


Modified Text: 
INPUT 


DELTA_T 

FRAME_BEAM_UNLOCKED 

FRAME_COUNTER 

K_MATRIX 

TDLR_ANGLES 

TDLR.COUNTER 

TDLR_GAIN 

TDLR_LOCK_TIME 

TDLR_OFFSET 

TDLR_STATE 

TDLR_VELOCITY 
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Software Requirements GCS Development Specification 
Formal Modification # 2.2-17 


Date: June 3, 1993 

Part of Specification Affected: 
Chapter 5 
TSP 


2.2-17.1 

Location: 

Page 75, title for P-Spec. 

Reason for Modification: 

In order to reflect the numbering in the new structured analysis figures. 
Action: 

Replace the title. 

Original Text: 

2.11 TSP - Temperature Sensor Processing 
Modified Text: 

TSP - Temperature Sensor Processing (P-Spec 2.1.5) 


2.2-17.2 

Location: 

Page 75, INPUT (list of variables that are inputs to this functional unit) 
Reason for Modification: 

The variable TS_STATUS should not have been included in the list of inputs. 
Action: 

Delete the variable TS_STATUS from the list of inputs. 

Original Text: 

INPUT 


Ml 

M2 

M3 

M4 

SS_TEMP 

T1 

T2 

T3 

T4 

THERMO_TEMP 

TS_STATUS 



Modified Text: 
INPUT 


Ml 

M2 

M3 

M4 

SS_TEMP 

T1 

T2 

T3 

T4 

THERMO_TEMP 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-18 

Date: June 3, 1993 

Part of Specification Affected: 

Chapter 5 

ARSP, ASP, CRCP, and TDSP 


2.2-18.1 

Location: 

ARSP, page 43 (with mod 2.2-5), title for P-Spec 
Reason for Modification: 

In order to reflect the numbering in the new structured analysis figures. 
Action: 

Replace the title. 

Original Text: 

2.2 ARSP - Altimeter Radar Sensor Processing 
Modified Text: 

ARSP - Altimeter Radar Sensor Processing (P-Spec 2.1.2) 

2.2-18.2 

Location: 

ASP, page 45, title for P-Spec 
Reason for Modification: 

In order to reflect the numbering in the new structured analysis figures. 
Action: 

Replace the title. 

Original Text: 

2.3 ASP - Accelerometer Sensor Processing 
Modified Text: 

ASP - Accelerometer Sensor Processing (P-Spec 2.1.1) 

2.2-18.3 

Location: 

CRCP, page 53, title for P-Spec 
Reason for Modification: 

In order to reflect the numbering in the new structured analysis figures. 
Action: 

Replace the title. 

Original Text: 

2.5 CRCP - Chute Release Control Processing 
Modified Text: 

CRCP - Chute Release Control Processing (P-Spec 2.3.3) 


2.2-18.4 

Location: 

TDSP, page 73, title for P-Spec 
Reason for Modification: 

In order to reflect the numbering in the new structured analysis figures. 
Action: 

Replace the title. 

Original Text: 

2.10 TDSP - Touch Down Sensor Processing 
Modified Text: 

TDSP - Touch Down Sensor Processing (P-Spec 2.1.6) 
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Software Requirements GCS Development Specification 
Formal Modification # 2.2-19 


Date: June 3, 1993 

Part of Specification Affected: 
BIBLIOGRAPHY 


2.2-19 

Location: 

Page 119, following reference [18] 

Reason for Modification: 

team wor/c was used for developing structured analysis charts. 

Action: 

Add reference for team work 
New Text: 

[19] teamwor/c/SA teamwor/c/RT User's Guide, Cadre Technologies, Inc., Providence, 
Rhode Island, Release 4.0, 1990. 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-20 


Date: June 3, 1993 

Part of Specification Affected: 
Chapter 5 
GP 


2 . 2 - 20.1 

Location: 

Page 55, title for P-Spec. 

Reason for Modification: 

In order to reflect the numbering In the new structured analysis figures. 
Action: 

Replace the title. 

Original Text: 

2.6 GP - Guidance Processing 
Modified Text: 

GP - Guidance Processing (P-Spec 2.2) 


2 . 2 - 20.2 

Location: 

Page 60, step labeled "PHASE 1 
Reason for Modification: 

The phrase "and the engines were not turned off in prior frame" is unnecessary because when 
the lander is in Phase 1 , the engines will not yet have been turned off. 

Action: 

Delete the text "and the engines were not turned off in prior frame" 

Original Text: 

PHASE 1 : If the altitude provided by the guidance processor is less than or equal to the 
ENGINES_ON_ALTITUDE and the engines were not turned off In prior frame, set GP PHASE 
_ 2.48 

Modified Text: 

PHASE 1 : If the altitude provided by the guidance processor is less than or equal to the 
ENGINES_ON_ALTITUDE, set GP_PHASE = 2. 48 

2.2-20.3 

Location: 

Page 61 (with mod 2.2-8), step labeled "PHASE A”, second paragraph. 

Reasons for Modification: 

The termination of GCS is not necessarily a requirement for the functional unit GP, but is actually a 
scheduling requirement; therefore, the conditions and procedures for termination of GCS would be 
more appropriate in the scheduling section. The text describing termination needs clarification. 

The control signal "END_GCS" is not used In the new structured analysis charts. 

Action: 

Delete the paragraph from the functional unit GP and include a modified version of it in the 
scheduling section (see Formal Modification 2.2-11.13). 

Original Text: 

It should be noted that under certain conditions, the next phase is 5 which means "END_GCS". 
This means that the implementation should stop itself at the end of the present subframe. Thus, in 
all cases, a GCS implementation should stop just after Communications Processing during the 
Guidance subframe, but before calling rendezvous. 

Modified Text: 

(none) 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-21 

Date: June 4, 1993 

Parts of Specification Affected: 

Chapter 5 
CP 


Location: 

Page 49, title for P-Spec. 

Reason for Modification: 

In order to reflect the numbering in the new structured analysis diagrams. 
Action: 

Replace the title. 

Original Text: 

2.4 CP - Communications Processing 
Modified Text: 

CP - Communications Processing (P-Spec 2.4) 


Location: 

Page 49, INPUT, (list of variables that are inputs to this functional unit) 

Reasons for Modification: 

Some of the variables in the Data Store GUIDANCE_STATE are not inputs to this processing unit. 
The variable SUBFRAME_COUNTER should be included as an input. The variable C_STATUS 
should not be included as an input (see Formal Modification 2.2-21 .9). The inputs are not listed in 
ascii sequence. 

Actions: 

The data store names GUIDANCE_STATE and SENSOR_OUTPUT have been replaced by the 
individual names of variables in those stores which are inputs to this functional unit. The variable 
SUBFRAME_COUNTER has been added to the input list. The variable C_STATUS has been 
deleted from the input list. The modified list of inputs has been arranged in ascii sequence. 

Original Text: 

INPUT 


AE_CMD 

C_STATUS 

COMM_SYNC_PATTERN 

FRAME_COUNTER 

GUIDANCE_STATE 

RE_CMD 

SENSOR_OUTPUT 
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Modified Text: 

INPUT 


AE_CMD 

AE_TEMP 

AR_STATUS 

ACCELERATION 

CHUTE_RELEASED 

CONTOUR_CROSSED 

GP_ALTiTUDE 

GP_PHASE 

GP_VELOCITY 

G_STATUS 

K_MATRIX 

RE_CMD 

SUBFRAME_COUNTER 

TDLR_STATUS 

TDS_STATUS 

TE_INTEGRAL 

VELOCITY_ERROR 


AE_STATUS 

AR_ALTITUDE 

ATMOSPHERIC_TEMP 

A_STATUS 

COMM_SYNC_PATTERN 

FRAME_COUNTER 

GP_ATTITUDE 

GP_ROTATION 

G_ROTATION 

K_ALT 

PEJNTEGRAL 

RE_STATUS 

TDLR_STATE 

TDLR_ VELOCITY 

TD_SENSED 

TS_STATUS 

YE_INTEGRAL 


Location: 

Page 49. Subsection labeled "PROCESS", first sentence 
Reason for Modification: 

The order given for the items In the data packet does not agree with the correct order qlven in 
Table 5.7. 

Action: 

Move "checksum Information" to the end of the list. 

Original Text: 

The data packet (PACKET) prepared for transmission is organized to sequentially contain a 
synchronization pattern, a sequence number, checksum information, new sample mask and the 
data itself. 

Modified Text: 

The data packet (PACKET) prepared for transmission is organized to sequentially contain a 
synchronization pattern, a sequence number, new sample mask, the data itself, and the checksum 
information. 


Location: ' 

Page 49, Subsection labeled "DETERMINE SEQUENCE NUMBER", last sentence 
Reason for Modification: 

The sentence was not explicit about the fact that the sequence number increases by one each 
subframe, and also the number 255 was incorrect. 

Action: 

Insert the phrase "increase by one every subframe, except that they" and change the text "255th" 
to "256th". 

Original Text: 

Sequence numbers repeat after the 255th packet, and can be calculated based on the 
FRAME_COUNTER and the subframe where the present call to CP was made. 


F-70 




Modified Text: 

Sequence numbers increase by one every subframe, except that the values repeat after the 256th 
packet. The sequence number can be calculated based on the values of the variables 
FRAME_COUNTER and SUBFRAME_COUNTER. 

2.2- 21.5 
Location: 

Page 49, Subsection labeled "PREPARE SAMPLE MASK", between second and third sentences. 
Reason for Modification: 

An explicit statement is needed regarding the functional units ARSP and TDLRSP. 

Action: 

Insert the text "The output variables from the functional units ARSP and TDLRSP, however, should 
not be transmitted when the variable FRAME_COUNTER is an even number." 

Original Text: 

"...mask and transmitted. Values that have been..." 

Modified Text: 

"...mask and transmitted. The output variables from the functional units ARSP and TDLRSP, 
however, should not be transmitted when the variable FRAME_COUNTER is an even number. 
Values that have been...” 

2 . 2 - 21.6 
Location: 

Pages 49-50, Subsection labeled "PREPARE SAMPLE MASK", the sentence which begins at the 
bottom of page 49 and continues at the top of page 50, and the second sentence on page 50. 
Reason for Modification: 

The first sentence is incorrect because some variables in GUIDANCE_STATE are never sent in 
the packet, and more clarity is needed in the second sentence regarding the correspondence 
between mask bits and variables to be sent. 

Action: 

Replace the two sentences. 

Original Text: 

A position should represent each variable contained in either GUIDANCE_STATE or 
SENSOR_OUTPUT in addition to AE_CMD and RE_CMD. These variables should be arranged 
as shown in table 5.5. 

Modified Text: 

Each bit position in the mask represents a particular variable listed in Table 5.5. The leftmost bit of 
the mask corresponds to AE_CMD, and moving across the mask from left to right, the next mask 
bit corresponds to the next variable in Table 5.5 (in row order). 

2.2-21.7 

Location: 

Page 50, Subsection labeled "PREPARE DATA SECTION, between the second and third 
sentences. 

Reason for Modification: 

The text needs some clarification regarding the exact manner in which the variables to be 
transmitfed should be packed into the data section. 

Action: 

Insert clarifying text between the second and third sentences. 

Original Text: 

"...do not have to be transmitted. The data are concatenated..." 

Modified Text: 

"...do not have to be transmitted. Once it has been determined which variables should be 
transmitted for this particular subframe, those variables should be packed into the data section. 
Although the length of the variable PACKET is fixed, the number of bytes of PACKET which 
contain actual variables to be transmitted will vary depending on the values of 
FRAME_COUNTER and SUBFRAME_COUNTER. The variables to be transmitted should be 
concatenated so that there are no unused bytes between the data to be transmitted. There may 
however be unueed bytoe tallowing the checksum. The date are concatenated..." 
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2 . 2 - 21.8 

Location: 

Page 50, Subsection labeled "CALCULATE CHECKSUM", following the last sentence in the 
section. 

Reason for Modification: 

The text needs some clarification regarding exactly where the checksum should be placed in the 
packet. 

Action: 

Insert clarifying text at the end of the paragraph. 

New Text: 

The checksum should be placed in the two bytes immediately following the last byte of actual data 
to be transmitted for this subframe. 

2.2-21.9 

Location: 

Page 50, Subsection labeled "SET COMMUNICATOR STATUS TO HEALTHY". 

Reason for Modification: 

The variable C_STATUS should be set before preparing the data section, so that the value 
transmitted in the packet will be the new value set in this subframe rather than the value that was 
set in the previous subframe. 

Action: 

Move the entire Subsection "SET COMMUNICATOR STATUS TO HEALTHY" so that it is before 
the Subsection "CONSTRUCT PACKET". 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-22 


Date: June 4, 1993 


Part of Specification Affected: 
Appendix A 


2 . 2 - 22.1 

Location: 

Page 105, title for the appendix. 

Reason for Modification: 

In order to reflect the new structured analysis diagrams. 

Action: 

Replace the title. 

Original Text: 

A. FORMAT DESCRIPTION FOR LEVEL 0, 1, 2 SPECIFICATIONS 
Modified Text: 

A. NOTATION FOR LEVELS 0, 1, 2, AND 3 SPECIFICATION 


2 . 2 - 22.2 

Location: 

Page 107, title for the appendix. 

Reason for Modification: 

In order to reflect the new structured analysis diagrams. 

Action: 

Replace the title. 

Original Text: 

A. FORMAT DESCRIPTION FOR LEVEL 0, 1, 2 SPECIFICATIONS 
Modified Text: 

A. NOTATION FOR LEVELS 0, 1, 2, AND 3 SPECIFICATION 


2.2-22.3 

Location: 

Page 107, first sentence. 

Reason for Modification: 

Reference to sources for development using structured analysis methods was not complete, and 
should be in reference. 

Action: . 

Add a second reference, and change to 
Original Text: 

"...advocated by Hatley [12.13]." 

Modified Text: 

"...advocated by Hatley [12,13] and Cadre's teamivor/c[19]." 


2.2-22.4 

Location: 

Page 107, entire third paragraph and first two sentences of the fourth 
paragraph. 

Reason for Modification: 

Inaccuracies. 
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Action: 

Replace the third paragraph and the first sentence of the fourth paragraph. 

Original Text: 

The data flow diagrams describe the processes, data flows, data stores, and data conditions. 
The data context diagram is the highest-level data flow diagram and represents the data flow for 
the entire system. Data conditions are represented by directed arcs with broken lines. 

The control flow diagrams describe processes, control signal flows, and stores. The control 
signal flows are depicted using directed arcs with broken lines. 

Modified Text: 

The data flow diagrams describe the processes, data flows, and data stores. The data context 
diagram is the highest-level data flow diagram and represents the data flow for the entire system. 

The control flow diagrams describe processes, control signal and data condition flows, control 
specifications, and data stores. The control signal and data condition flows are depicted using 
directed arcs with broken lines. 


2.2-22.5 

Location: 

Page 107, fourth paragraph, next-to-last sentence. 

Reason for Modification: 

Statement is unclear and unnecessary. 

Action: 

Delete the entire sentence. 

Original Text: 

This duplication of processes is consistent with the approach of slaving the control flow to the 
data flow. 

Modified Text: 

(none) 


2 . 2 - 22.6 

Location: 

Page 107, last sentence 
Reason for Modification: 

To reflect new structured analysis diagrams. 

Action: 

Change phrase at end of sentence. 

Original Text: 

The Data Requirements Dictionary contains definitions for both data and control signals. 
Modified Text: 

The Data Requirements Dictionary contains definitions for data, data conditions, control signals, 
and group flows. 


2.2-22.7 

Location: 

Page T07, following the last sentence 
Reason for Modification: 

To reflect new structured analysis diagrams. 

Action: 

Add an additional paragraph to describe the meanings and definitions, etc. for the new structured 
analysis diagrams. 

New Text: 

Following is a list of definitions and explanations for the structured analysis diagrams: 

1 . The data and control flow names on the directed arcs in the structured analysis figures can 
be found in the Data Requirements Dictionary Part I, while the group flow names on the arcs 
can be found in the Data Requirements Dictionary Part III. 

2. In the Process Activation Tables, the first column contains the inputs. The second set of 
columns (separated by two vertical lines) contains the cells which indicate whether a process 
is to be activated or deactivated. A blank cell indicates that the process is deactivated. An 
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integer indicates that the process is activated. A process whose cell contains the integer "n" 
must complete before the process with integer "n+1" is activated. All processes whose cells 
contain the same integer can be activated in any order. The third set of columns, if present, 
represents the output values for control signals. 

3. The meanings for the symbols used in the expressions for inputs are: 

= equal 

not equal 
logical NOT 
& logical AND 

| logical OR 

() grouping (expression inside parentheses is evaluated first) 


2 . 2 - 22.8 

Location: 

Page 108, graphical symbols 
Reason for Modification: 

To reflect the new structured analysis diagrams. 

Action: 

In the title, the word "FLOW” has been changed to "STRUCTURED ANALYSIS". 

The rectangular symbol for PROCESS MODULE has been replaced with a bubble. 

The dashed rectangular symbol for SOURCE OR SINK has been replaced with a solid rectangle. 
The solid lines which represent a DATA STORE have been moved closer to each other. 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-23 

Date: June 4, 1993 

Part of Specification Affected: 

Chapter 6 

PART I. DATA ELEMENT DESCRIPTIONS 

2.2-23.1 

Location: 

Pages 83 through and including page 95 (with mod 2.2-6), all entries 
Reason for Modification: 

P-Spec numbers for functional units are unnecessary. 

Action: 

P-Spec numbers for functional units were deleted wherever they occurred. 


2.2-23.2 

Location: 

Page 83, A_ACCELERATION, "USED IN" field 
Reason for Modification: 

Functional unit CP was omitted. 

Action: 

Functional unit CP was added. 

Original Text: 

NAME: A_ACCELERATION 
USED IN: 2 .1 AECLP, 2.3 ASP, 2.6 GP 
Modified Text: 

NAME: A_ACCELERATION 
USED IN: AECLP, ASP, CP, GP 


2.2-23.3 

Location: 

Page 83, AE_STATUS, "ATTRIBUTE" field 
Reason for Modification: 

Attribute is incorrect. 

Action: 

Attribute was changed from "data condition" to "data". 
Original Text: 

NAME: AE_STATUS 
ATTRIBUTE: data condition 
Modified Text: 

NAME: AE_STATUS 
ATTRIBUTE: data 


2.2-23.4 

Location: 

Page 85, following entry for CL 
Reason for Modification: 

New structured analysis charts use new control signal, CLP_DONE. 
Action: 

New entry for CLP_DONE was added. 
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New Text: 

NAME: CLP_DONE 

DESCRIPTION: Control signal which indicates whether or not Control Law 
Processing (unction has completed. 

USED IN: 2. RUN_GCS 
UNITS: none 

tomc l^LSE: running of Control Law Processing (unction incomplete: 

l RUE: running of Control Law Processing function completel 

DATATYPE: logical‘1 

ATTRIBUTE: control 

DATA STORE LOCATION: none 

ACCURACY: N/A 


2.2-23.5 

Location: 

Page 86, ENGINES_ON_ALTITUDE, "ATTRIBUTE" field 
Reason for Modification: 

Attribute is incorrect. 

Action: 

Attribute was changed from "data condition" to "data" 
Original Text: 

NAME: ENGINES_ON_ALTITUDE 
ATTRIBUTE: data condition 
Modified Text: 

NAME: ENGINES_ON_ALTITUDE 
ATTRIBUTE: data 


2.2-23.6 

Location: 

Page 86. FRAME_COUNTER, "USED IN" field 
Reason for Modification: 

Functional unit ARSP was omitted. 

Action: 

Functional unit ARSP was added. 

Original Text: 

NAME: FRAME_COUNTER 
USED IN: 2.1 AECLP, 2.4 CP, 2.6 GP, 2.9 TDLRSP 
Modified Text: 

NAME: FRAME_COUNTER 

USED IN: AECLP, ARSP, CP, GP, TDLRSP 


2.2-23.7 

Location: 

Page 86, FRAME_COUNTER, "ACCURACY" field 
Reason for Modification: 

This variable is not an output from GCS. 

Action: 

ACCURACY was changed from "TBD" to "N/A" 
Original Text: 

NAME: FRAME_COUNTER 
ACCURACY: TBD 
Modified Text: 

NAME: FRAME COUNTER 
ACCURACY: N/A 
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2.2-23.8 

Location: 

Page 88, GP_ATTITUDE, "DESCRIPTION" field 
Reason for Modification: 

The description is inaccurate. 

Action: 

The description was replaced. 

Original Text: 

NAME: GP_ATTITUDE 

DESCRIPTION: attitude as seen by guidance processor 
Modified Text: 

NAME: GP_ATTITUDE 
DESCRIPTION: direction cosine matrix 


2.2- 23.9 
Location: 

Page 88, GP_ATTITUDE, "USED IN" field 
Reason for Modification: 

Functional unit AECLP was omitted. 

Action: 

Functional unit AECLP was added. 

Original Text: 

NAME: GP_ATTITUDE 
USED IN: 2.4 CP, 2.6 GP 
Modified Text: 

NAME: GP_ATTITUDE 
USED IN: AECLP, CP, GP 

2.2- 23.10 
Location: 

Page 88, GP_PHASE, "ATTRIBUTE" field 
Reason for Modification: 

The attribute should be "data condition" 

Action: 

The attribute was changed from "data" to "data condition" 
Original Text: 

NAME: GP_PHASE 
ATTRIBUTE: data 
Modified Text: 

NAME: GP_PHASE 
ATTRIBUTE: data condition 


2.2-23.11 

Location: 

Page 88, GRAVITY, "USED IN" field 
Reason fof Modification: 

Functional unit AECLP was omitted. 
Action: 

Functional unit AECLP was added. 
Original Text: 

NAME: GRAVITY 
USED IN: 2.6 GP 
Modified Text: 

NAME: GRAVITY 
USED IN: AECLP, GP 
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2.2-23.12 

Location: 

Page 89, GSP_DONE, "UNITS" field 
Reason for Modification: 

Units are incorrect 
Action: 

Change units. 

Original Text: 

NAME: GSP_DONE 
UNITS: Binary 
Modified Text: 

NAME: GSP_DONE 
UNITS: none 


2.2-23.13 

Location: 

Page 89, GUIDANCE_STATE, entire entry 
Reason for Modification: 

The data stores are listed in Data Requirements Dictionary Part II 
Action: 

The entire entry for GUIDANCE_STATE was deleted. 

Original Text: 

NAME: GUIDANCE_STATE 

DESCRIPTION: Data store containing all the status, 

state, and sensed variables in alphabetical order. 

USED IN: 2.1 AECLP, 2.2 ARSP, 2.3 ASP, 2.4 CP, 

2.5 CRCP, 2.7 GSP, 2.6 GP, 2.8 RECLP, 2.9 
TDLRSP, 2.10 TDSP, 2.1 1 TSP 
UNITS: N/A 
RANGE: N/A 
DATA TYPE: common 
ATTRIBUTE: data store 
DATA STORE LOCATION: GUIDANCE_STATE 
ACCURACY: N/A 
Modified Text: 

(no entry) 


2.2-23.14 

Location: 

Page 91 (with mod 2.2-6), RE_SWITCH, "USED IN" field 
Reason for Modification: 

Functional unit RECLP was omitted. 

Action: 

Functional unit RECLP was added. 

Original Text: 

NAME: 'RE_SWITCH 
USED IN: 2.6 GP 
Modified Text: 

NAME: RE_SWITCH 
USED IN: GP, RECLP 


2.2-23.15 

Location: 

Page 91 (with mod 2.2-6), following entry for RECLP_DONE 
Reason for Modification: 

New structured analysis charts use new control signal, RENDEZVOUS 
Action: 

Add entry for RENDEZVOUS. 
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New Text: 

NAME: RENDEZVOUS 

DESCRIPTION: Control signal which indicates whether or not 
GCS_SIM_RENDEZVOUS is to be activated. 

USED IN: 2. RUN_GCS 
UNITS: none 

RANGE: [FALSE: GCS_SIM_RENDEZVOUS is not to be activated, 
TRUE: GCS_SIM_RENDEZVOUS is to be activated] 

DATATYPE: logical* 1 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 


2.2-23.16 

Location: 

Page 92, RUN_PARAMETERS, entire entry 
Reason for Modification: 

The data stores are listed in Data Requirements Dictionary Part II 
Action: 

The entire entry for RUN_PARAMETERS was deleted. 

Original Text: 

NAME: RUN_PARAMETERS 
DESCRIPTION: Data store containing all the run 
parameters in alphabetical order. 

USED IN: 2.1 AECLP, 2.2 ARSP, 2.3 ASP, 2.4 CP, 

2.6 GP, 2.7 GSP, 2.8 RECLP, 2.9 TDLRSP, 2.10 

TDSP, 2.11TSP 

UNITS: N/A 

RANGE: N/A 

DATATYPE: common 

ATTRIBUTE: data store 

DATA STORE LOCATION: RUN_PARAMETERS 
ACCURACY: N/A 
Modified Text: 

(no entry) 


2.2-23.17 

Location: 

Page 92, SENSOR_OUTPUT, entire entry 
Reason for Modification: 

The data stores are listed in Data Requirements Dictionary Part II 
Action: 

The entire entry for SENSOR_OUTPUT was deleted 
Original Text: 

NAME: SENSOR_OUTPUT 

DESCRIPTION: Data store containing all the sensor output in 
alphabetical order. 

USED IN: 2.1 AECLP, 2.2 ARSP, 2.3 ASP, 2.4 CP, 

2.6 GP, 2.7 GSP, 2.8 RECLP, 2.9 TDLRSP, 2.10 
TDSP, 2.11 TSP 
UNITS: N/A 
RANGE: N/A 
DATA TYPE: common 
ATTRIBUTE: data store 
DATA STORE LOCATION: SENSOR_OUTPUT 
ACCURACY: N/A 
Modified Text: 

(no entry) 
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2.2-23.18 

Location: 

Page 92, before entry for SS_TEMP 
Reason for Modification: 

New structured analysis charts use new control signal, SP DONE 
Action: 

Add entry for SP_DONE 
New Text: 

NAME: SP_DONE 

DESCRIPTION: Control signal which indicates whether or not Sensor 
Processing function has completed. 

USED IN: 2. RUN_GCS 
UNITS: none 

RANGE: [FALSE: running of Sensor Processing function incomplete; 
TRUE: running of Sensor Processing function completel 
DATATYPE: logical^ 

ATTRIBUTE: control 

DATA STORE LOCATION: none 

ACCURACY: N/A 


2.2- 23.19 
Location: 

Page 92, following entry for SS_TEMP 
Reason for Modification 

New variable SUBFRAME_COUNTER is needed. 

Action: 

New entry for SUBFRAME_COUNTER was added. 

New Text: 

NAME: SUBFRAME_COUNTER 

DESCRIPTION: Counter containing the number of the present subframe 
USED IN: CP 
UNITS: none 
RANGE: [1,3] 

DATA TYPE: lnteger*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 

2.2- 23.20 
Location: 

Page 93, TDLRSP_DONE, "RANGE" field 
Reason for Modification: 

"TDSP" is incorrect. 

Action: 

"TDSP" was replaced by "TDLRSP”. 

Original Text: 

NAME: TDLRSP_DONE 

RANGE: [0: running of task 2.11 TDLRSP 

incomplete, 1 : running of task 2.10 TDSP complete] 

Modified Text: 

NAME: TDLRSP_DONE 

RANGE: [0: running of task TDLRSP 

incomplete, 1: running of task TDLRSP complete] 
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2.2-23.21 

Location: 

Page 93, TDLRSP_SWITCH, entire entry 
Reason for Modification: 

The variable TDLRSP_SWITCH is not needed. 
Action: 

The entire entry for TDLRSP_SWITCH was deleted. 
Original Text: 

NAME: TDLRSP_SWITCH 
DESCRIPTION: Flag indicating whether or not the 
touch down landing radar sensor processor is turned 
on. 

USED IN: 1. INIT_GCS 
UNITS: none 

RANGE: [0: processor is off, 1 : process is on.] 
DATATYPE: logical‘1 
ATTRIBUTE: data condition 
DATA STORE LOCATION: GUIDANCE_STATE 
ACCURACY: N/A 
Modified Text: 

(no entry) 


2.2-23.22 

Location: 

Page 94, TDSP_SWITCH, entire entry 
Reason for Modification: 

The variable TDSP_SWITCH is not needed. 

Action: 

The entire entry for TDSP_SWITCH was deleted. 

Original Text: 

NAME: TDSP_SWITCH 

DESCRIPTION: Flag indicating whether or not the 
touch down sensor is turned on. 

USED IN: O.GCS 
UNITS: none 

RANGE: [0: touch down sensor is off, 1 : touch down sensor is on.l 
DATATYPE: logical* 1 
ATTRIBUTE: data condition 
DATA STORE LOCATION: GUIDANCE_STATE 
ACCURACY: N/A 
Modified Text: 

(no entry) 


2.2-23.23 

Location: 

Page 94' TEJNTEGRAL, "USED IN" field 
Reason for Modification: 

Functional unit GP was omitted. 

Action: 

Functional unit GP was added. 

Original Text: 

NAME: TEJNTEGRAL 
USED IN: 2.1 AECLP, 2.4 CP 
Modified Text: 

NAME: TEJNTEGRAL 
USED IN: AECLP, CP, GP 
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2.2-23.24 

Locations: 

Page 83, AECLP_DONE, "RANGE" field 
Page 84, ARSP_DONE, "RANGE" field 
Page 84, ASP_DONE, "RANGE” field 
Page 85, CP_DONE, "RANGE" field 
Page 85, CRCP_DONE, "RANGE" field 
Page 88, GP_DONE, "RANGE" field 
Page 89, GSP_DONE, "RANGE" field 
Page 89, INIT_DONE, "RANGE" field 
Page 91, RECLP_DONE, "RANGE" field 
Page 92, RUN_DONE, "RANGE" field 
Page 93, TDLRSP_DONE, "RANGE" field 
Page 94, TDSP_DONE, "RANGE" field 
Page 95, TSP_DONE, "RANGE" field 
Reason for Modification: 

To reflect values used in new structured analysis diagrams 
Action: 

The value "0” was replaced by "FALSE", and the value "1" was replaced by "TRUE". 
Original Text: 

"RANGE: [0: " ... " incomplete, 1 : " ... " complete]" 

Modified Text: 

"RANGE: [FALSE: " ... " incomplete, TRUE: " ... " complete]" 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-24 


Date: June 7, 1993 


Part of Specification Affected: 

Chapter 6 

PART II. CONTENTS OF DATA STORES 


2.2-24.1 

Location: 

Pages 97 through and including page 100, "USED BY" Column for all entries. 
Reason for Modification: 

P-Spec numbers for functional units are unnecessary. 

Action: 

P-Spec numbers for functional units were removed. 


2.2-24.2 

Location: 

Page 97, Table 6.1, GP_ATTITUDE, "USED BY" Column 
Reason for Modification: 

Functional unit AECLP was omitted. 

Action: 

Functional unit AECLP was added. 

Original Text: 

GP_ATTITUDE 2.4 CP, 2.6 GP 

Modified Text: 

GP_ATTITUDE AECLP, CP, GP 


2.2-24.3 

Location: 

Page 97, Table 6.1, RE_SWITCH, "USED BY" Column 
Reason for Modification: 

For consistency, INIT_GCS should not be included. 

Action: 

INIT_GCS was deleted. 

Original Text: 

RE_S WITCH INIT_GCS, 2.6 GP, 2.8 RECLP 

Modified Text: 

RE_SWITCH GP, RECLP 


2.2-24.4 

Location: 

Page 97, Table 6.1, TDLR_STATE, "USED BY" Column 
Reason for Modification: 

Functional unit GP should not be included. 

Action: 

Functional unit GP was deleted. 

Original Text: 

TDLR_STATE 2.4 CP, 2.6 GP, 2.9 TDLRSP 

Modified Text: 

TDLR_STATE CP, TDLRSP 
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2.2-24.5 

Location: 

Page 97, Table 6.1, TDLRSP_SWITCH 
Reason for Modification: 

The variable TDLRSP_SWITCH is not needed. 
Action: 

Entire entry for TDLRSP_SWITCH was deleted. 
Original Text: 

TDLRSP_SWITCH INIT_GCS 

Modified Text: 

(no entry) 


2.2-24.6 

Location: 

Page 97, Table 6.1, TDSP_SWITCH 
Reason for Modification: 

The variable TDSP_SWITCH is not needed. 
Action: 

Entire entry for TDSP_SWITCH was deleted. 
Original Text: 

TDSP_SWITCH O.GCS 

Modified Text: 

(no entry) 


2.2-24.7 

Location: 

Page 97, Table 6.1, TEJNTEGRAL, "USED BY" Column 
Reason for Modification: 

Functional unit GP was omitted. 

Action: 

Functional unit GP was added. 

Original Text: 

TEJNTEGRAL 2.1 AECLP, 2.4 CP 

Modified Text: 

TEJNTEGRAL AECLP, CP, GP 


2.2-24.8 

Location: 

Page 98, Table 6.2, FRAME_COUNTER, "USED BY" Column 
Reason for Modification: 

Functional unit ARSP was omitted. 

Action: 

Functional unit ARSP was added. 

Original Text: 

FRAME_COUNTER 2.1 AECLP, 2.4 CP, 2.6 GP, 2.9 TDLRSP 

Modified Text: 

FRAME_COUNTER AECLP, ARSP, CP, GP, TDLRSP 


2.2-24.9 

Location: 

Page 98, Table 6.2, between entries for SS_TEMP and TD_COUNTER 
Reason for Modification: 

New variable SUBFRAME_COUNTER is in the EXTERNAL data store. 
Action: 

SUBFRAME_COUNTER was added. 
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Original Text: 

SS_TEMP 2.11 TSP 

TD_COUNTER 2.10 TDSP 

Modified Text: 

SS_TEMP TSP 

SUBFRAME_COUNTER CP 
TD_COUNTER TDSP 


2.2-24.10 

Location: 

Page 99, Table 6.4, DELTAJT, "USED BY" Column 
Reason for Modification: 

Functional unit AECLP was omitted. 

Action: 

Functional unit AECLP was added. 

Original Text: 

DELTAJT 2.6 GP, 2.8 RECLP, 2.9 TDLRSP 

Modified Text: 

DELTAJT AECLP, GP, RECLP, TDLRSP 


2.2-24.11 

Location: 

Page 99, Table 6.4, GRAVITY, "USED BY" Column 
Reason for Modification: 

Functional unit AECLP was omitted. 

Action: 

Functional unit AECLP was added. 

Original Text: 

GRAVITY 2.6 GP 

Modified Text: 

GRAVITY AECLP, GP 


F-86 



Software Requirements GCS Development Specification 


Formal Modification # 2.2-25 


Date: June 7, 1993 


Part of Specification Affected: 

Chapter 6 

PART III. CONTROL VARIABLES, DATA CONDITIONS, AND INITIALIZATION DATA 

2.2-25.1 

Location: 

Pages 101 through and including page 103, "USED BY" Column 
Reason for Modification: 

P-Spec numbers for functional units are unnecessary. 

Action: 

P-Spec numbers for functional units were removed. 


2.2-25.2 

Location: 

Page 101, Part III title 
Reason for Modification: 

Title improvement 
Action: 

Replace title. 

Original Text: 

PART III. CONTROL VARIABLES, DATA CONDITIONS, AND 
INITIALIZATION DATA 
Modified Text: 

PART III. CONTROL SIGNALS, DATA CONDITIONS, AND GROUP FLOWS. 


2.2-25.3 

Location: 

Page 101, Table 6.5, title and contents 
Reason for Modification: 

Title improvement 

The control variable INIT_DONE was omitted. 

Three additional control variables, namely CLP_DONE, RENDEZVOUS, and SP_DONE are used 
in the new structured analysis diagrams. 

Actions: 

The title was changed. 

The control variables INIT_DONE, CLP_DONE, RENDEZVOUS, and SP_DONE were added. 
Original text: 
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Table 6.5: CONTROL VARIABLES (OPTIONAL USAGE) 


CONTROL VARIABLE NAME 
AECLP_DONE 
ARSP_DONE 
ASP_DONE 
CP_DONE 114 
CRCP_DONE 
GP_DONE 
GSP_DONE 
RECLP_DONE 115 
RUN_DONE 116 
TDLRSP_DONE 
TDSP_DONE 
TSP_DONE 


Modified text: 

Table 6.5: CONTROL SIGNALS (OPTIONAL USAGE) 


CONTROL SIGNAL NAME 
AECLP_DONE 
ARSP_DONE 
ASP_DONE 
CLP_DONE 
CP_DONE 114 
CRCP_DONE 
GP_DONE 
GSP_DONE 
INIT_DONE 
RECLP_DONE 115 
RENDEZVOUS 
RUN_DONE 116 
SP_DONE 
TDLRSP_DONE 
TDSP_DONE 
TSP_DONE 


2.2-25.4 

Location: 

Page 101, Table 6.6, contents 
Reason for Modification: 

The variables AE_SWITCH, CONTOUR_CROSSED, RE_SWITCH and GP_PHASE were 
omitted. 

Action: 

The variables AE_SWITCH, CONTOUR_CROSSED, RE_SWITCH, and GP_PHASE were 
added. 

Original text: 
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Table 6.6: DATA CONDITIONS (REQUIRED USAGE) 


DATA CONDITION VARIABLE NAME 
AEJTEMP 
CHUTE_RELEASED 
TD_SENSED 
TDLR STATE 


Modified text: 

Table 6.6: DATA CONDITIONS (REQUIRED USAGE) 


DATA CONDITION VARIABLE NAME 
AE_SWITCH 
AE_TEMP 
CHUTE_RELEASED 
CONTOUR_CROSSED 
GP_PHASE 
RE_S WITCH 
TD_SENSED 
TDLR STATE 


2.2-25.5 

Location: - 

Page 102, Table 6.7, DELTA_T, "USED BY" Column 
Reason for Modification: 

Functional units AECLP, RECLP, and TDLRSP were omitted. 
Action: 

Functional units AECLP, RECLP, and TDLRSP were added. 
Original text: 

DELTA_T 2.6 GP 

Modified text: 

DELTA_T AECLP, GP, RECLP, TDLRSP 


2.2-25.6 

Location: 

Page 102, Table 6.7, FRAME_COUNTER, "USED BY" Column 
Reason for Modification: 

Functional unit ARSP was omitted. 

Action: 

Functional unit ARSP was added. 

Original text: 

FRAME_COUNTER 2.1 AECLP, 2.4 CP, 2.6 GP, 2.9 TDLRSP 
Modified text: 

FRAME_COUNTER AECLP. ARSP, CP, GP, TDLRSP 


2.2-25.7 

Location: 

Page 102, Table 6.7, GP_ALTITUDE, "USED BY" Column 
Reason for Modification: 

Functional unit CP was omitted, and the order of units is incorrect. 
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Action: 

Functional unit CP was added, and the order was corrected. 
Original text: 

GP_ALTITUDE 2.6 GP, 2.1 AECLP 

Modified text: 

GP_ALTITUDE AECLP, CP, GP 


2.2-25.8 

Location: 

Page 102, Table 6.7, GP_ATTITUDE, "USED BY" Column 
Reason for Modification: 

Functional units AECLP and CP were omitted. 

Action: 

Functional units AECLP and CP were added. 

Original text: 

GP_ATTITUDE 2.6 GP 

Modified text: 

GP_ATTITUDE AECLP, CP, GP 


2.2-25.9 

Location: 

Page 102, Table 6.7, GP_ROTATION, "USED BY" Column 
Reason for Modification: 

Functional units AECLP and CP were omitted, and RECLP should not have been included 
Action: 

Functional units AECLP and CP were added, and RECLP was deleted. 

Original text: 

GP_ROTATION 2.6 GP, 2.8 RECLP 

Modified text: 

GP_ROTATION AECLP, CP, GP 


2.2-25.10 

Location: 

Page 1 02, Table 6.7, GP_VELOCITY, "USED BY" Column 
Reason for Modification: 

Functional units AECLP and CP were omitted. 

Action: 

Functional units AECLP and CP were added. 

Original text: 

GP_VELOCITY 2.6 GP 

Modified text: 

GP_VELOCITY AECLP, CP, GP 


2.2-25.11 

Location: 

Page 102, Table 6.7, GRAVITY, "USED BY" Column 
Reason for Modification: 

Functional unit AECLP was omitted. 

Action: 

Functional unit AECLP was added. 

Original text: 

GRAVITY 2.6 GP 

Modified text: 

GRAVITY AECLP, GP 


F-90 



2.2-25.12 

Location: 

Page 103, Table 6.7, RE_SWITCH,"USED BY” Column 
Reason for Modification: 

INIT_GCS should not have been included. 

Action: 

INIT_GCS was deleted. 

Original text: 

RE_SWITCH INIT_GCS, 2.6 GP, 2.8 RECLP 

Modified text: 

RE_SWITCH GP, RECLP 


2.2-25.13 

Location: 

Page 103, Table 6.7, between SS_TEMP and T1 
Reason for Modification: 

New variable SUBFRAME_COUNTER is initialized. 
Action: 

Variable SUBFRAME_COUNTER was added 


Original text: 

SS_TEMP 2.11 TSP 

T1 2.11 TSP 

Modified text: 

SS_TEMP TSP 

SUBFRAME_COUNTER CP 
T1 TSP 


2.2-25.14 

Location: 

Page 103, Table 6.7, between T4 and TD_SENSED 
Reason for Modification: 

The variable TD_COUNTER was omitted from the table 
Action: 


Variable TD_COUNTER was added. 

Original text: 

T4 2.11 TSP 

TD_SENSED 2.4 CP, 2.6 GP. 2.10 TDSP 

Modified text: 


T4 

TD_COUNTER 

TD_SENSED 


TSP 

TDSP 

CP, GP, TDSP 


2.2-25.15 
Location: ' 

Page 103, Table 6.7, TDLR_COUNTER,"USED BY" Column 
Reason for Modification: 

Functional unit TDSP is incorrect. 

Action: 

Functional unit TDSP was replaced by TDLRSP. 

Original text: 

TDLR_COUNTER 2.10 TDSP 

Modified text: 

TDLR_COUNTER TDLRSP 
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2.2-25.16 

Location: 

Page 103, Table 6.7, TDLR_ST ATE, "USED BY" Column 
Reason for Modification: 

Functional unit GP should not have been included 
Action: 

Functional unit GP was deleted. 

Original text: 

TDLR_STATE 2.4 CP, 2.6 GP, 2.9 TDLRSP 

Modified text: 

TDLR_STATE CP, TDLRSP 


2.2-25.17 

Location: 

Page 103, Table 6.7, TDLRSP_SWITCH 
Reason for Modification: 

The variable TDLRSP_SWITCH is not needed. 
Action: 

Entire entry for TDLRSP_SWITCH was deleted. 
Original text: 

TDLRSP_SWITCH INIT_GCS 

Modified text: 

(no entry) 


2.2-25.18 

Location: 

Page 103, Table 6.7, TDSP_SWITCH 
Reason for Modification: 

The variable TDSP_SWITCH is not needed. 
Action: 

Entire entry for TDSP_SWITCH was deleted. 
Original text: 

TDSP_SWITCH O.GCS 

Modified text: 

(no entry) 


2.2-25.19 

Location: 

Page 103, Table 6.7, TEJNTEGRAL, "USED BY" Column 
Reason for Modification: 

The functional unit GP was omitted. 

Action: 

Functional unit GP was added. 

Original text: 

TEJNTEGRAL AECLP, 2.4 CP 

Modified text: 

TEJNTEGRAL AECLP, CP, GP 


2.2-25.20 

Location: 

Page 104 

Reason for Modification: 

Additional group flows were used in the new structured analysis charts. 
Action: 

Add Tables 6.8, 6.9, 6.10, 6.11, and 6.12. 
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Table 6.8: TEMP DATA 


VARIABLE NAME 

SS_TEMP 

THERMO_TEMP 

Table 6.9: SENSOR_DATA 

VARIABLE NAME 

A_COUNTER 

AR_COUNTER 

TDLR_COUNTER 

G_COUNTER 

TEMP_DATA 

TD_COUNTER 

Table 6.10: OUTPUT_DATA 

VARIABLE NAME 

AE_CMD 

RE_CMD 

PACKET 

Table 6.1 1 : OUTPUT_CONTROL 

VARIABLE NAME 

AE_SWITCH 

RE_SWITCH 

CHUTE_RELEASED 

Table 6.12: FRAME_DATA 

VARIABLE NAME 

FRAME_COUNTER 

SUBFRAME__COUNTER 
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Software Requirements GCS Development Specification 

Formal Modification # 2.2-26 


Dale: June 7, 1993 


Part of Specification Affected: 
INTRODUCTION 
EXCEPTION HANDLING 


2.2-26 

Location: 

Page16, paragraph labeled "UPPER OR LOWER LIMIT EXCEEDED" 

Reason for Modification: 

The fact that the RUN_PARAMETERS and EXTERNAL data stores need not be checked for 
limits was omitted. Also, the fact that it is not necessary for the functional unit CP to make any 
checks for limits was omitted. 

Action: 

Change text to include the additional information. 

Original Text: 

The current value for a data element exceeds its upper or lower limit as specified in the 
range section In the DATA DICTIONARY. 

Modified Text: 

The current value for a data element In the GUIDANCE_STATE or SENSOR_OUTPUT data 
store exceeds Its upper or lower limit as specified in the range section In the Data 
Requirements Dictionary Part I. The data elements in the RUN_PARAMETERS and 
EXTERNAL data stores need not be checked for limit exceeded. In addition, it is not necessary 
for the functional unit CP to check any data elements for limit exceeded. 
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Support Documentation Change Report 


page 1 of 3_ 


1 1. Configuration Item 

2. Date 

3. Formal Modification #: 

Software Requirements GCS Development 

December 

2.2 - 27 

| Specification Version 2.2 

23, 1993 



APPENDIX C. NUMERICAL INTEGRATION INSTRUCTIONS 
Page 1 18, immediately following the last paragraph. 

Table of Contents 

5. Reason for Modification: 


Clarification is needed in the adaptation of the Runge-Kutte fourth-order method to the GCS software for the 
Guidance Processing functional unit. 


6. Modification: 

Action: Add new text containing the clarification to the end of Appendix C. 

New Text: 

ADAPTATION OF RUNGE-KUTTE FOURTH-ORDER METHOD FOR SIMULTANEOUS EQUATIONS TO THE GCS 
SOFTWARE 

In the .ease where the Runge-Kutte method has been selected for integration in the Guidance Processing functional unit, the 
following gives information on how it is to be applied to GCS. The notation and formulas presented here are merely’one 
icpicsentation ot the Runge-Kutte method and its adaptation to GCS. The soitware designer/implementer may vary the notation 
and/or the loim of the equations as long as the algorithm used is equivalent to the one presented here. 

The Runge-Kutte tourth-order method (lor one dependent variable only) can be summarized as follows: 

Given: 

Let dy/dx = f(x,y) 

Let h represent the interval between equidistant values of x 
Let the initial values for x and y be xO and yO respectively 
Let xl = xO + h 
The problem is to estimate y 1 

The solution is: 
y 1 = y() + k 

k = 1/6 x (kl + 2x(k2 + k3) + k4) 
where: 

k i = hx f(xO, yO) 
k2 = h x f(xO + lx/2, yO + k 1/2) 
k3 = h x f(xO + h/2, yO + k2/2) 
k4 = h x l(xO + h, yO + k3) 


7. SQA Signature & Date: 


Original Signed by 
George Finelli 
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a. Report #: 2.2-27 


Support Documentation Change Report Continuation 

.... page -2- °f JL 


b. Notes/Explanation (Please reference appropriate section number) 

The GCS problem to be solved is as follows: 

Simultaneously calculate current values for the variables GP_ATTITUDE, GP_VELOCITY, and GP_ALTITUDE, using the 
equations for the corresponding derivatives given in GUIDANCE PROCESSING (P-Spec 2.2), Table 5.8. 

Adaptation to GCS of the Runge-Kutte fourth-order method for simultaneous equations 

In the discussion that follows, let the "dependent" variables refer to GP_ATTITUDE, GP_VELOCITY, and GP_ALTITUDE 
and let the "sensor" variables refer to G_ROTATION, A_ACCELERATION, K_MATRIX, TDLR_VELOCITY, K_ALT, and 
AR_ALTITUDE. In the Runge-Kutte method, it is assumed that the derivative for y can be obtained as a function of the dependent 
and independent variables. In GCS, the derivative for each of the dependent variables is a function of some subset of the 
dependent variables and some subset of the sensor variables. The values for the sensor variables are only available to GCS at 
discrete values ot time, namely at any time which is an integer multiple of the value of DELTA_T. It is therefore not possible to 
calculate derivatives at the midpoint between two frames. The mapping of the Runge-Kutte independent variable to the GCS time 
interval is shown below. This mapping should be used, as it will ensure that derivatives can be calculated as required. 

Runge-Kutte 


< 

1 

h 

_ 1 

- > 
1 


x 0 

xo + li/2 
GCS 

X 1 


< DELTA T- — 

1 

— ->< DELTA T 

1 

- > 
1 


t2 

tl 

to 

Time 

2 

u-2 

where: 

h = 2 x DELTA_T 

1 

0 

History Subscript 

n- 1 

11 

Frumu Number 

tO present time (time for the current frame) 

' ** - ‘ DELTA_T (time one frame ago) 

t2 = tO - (2 x DELTA_T) (time two frames ago) 



The Algorithm 

The following is intended to be a conceptual representation of the Runge-Kutte algorithm as applied to GCS. It is not intended 
to be pseudocode or actual code In this discussion, the subscripts for arrays have been omitted except for the hism^slscrb, 

^ vfi P Tt W1Cre J ‘ S i ’ ’ T Ti ," S ', iaS bCen d ° ne hCre ' n ° rder t0 present the conce Pts involved concisely, but without 

low-level details. The previously calculated values of the dependent variables at tl, although available, are not to be used Also 

note that the history values of the dependent and sensor variables with subscripts of 3 and 4 are not used in this adaptation of 
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Support Documentation Change Report Continuation 


a. Kepori if . 2 : 2 - 2 / 


b. Notes/Explanation (Please reference appropriate section number) 

Notation 

Let k 1 , k2, k3, k4 each represent a 3 x 3 array to hold estimate tor change in attitude. 

Let II, 12, 13, 14 each represent a vector of size 3 to hold estimate tor change in velocity. 

Let m 1 , 111 2, m3, tn4 each represent a scalar to hold estimate for change in altitude. 

Let SENS_ATT(j) icpresent the G_ROTATION array with time history subscript j, where j is 0 1 or 2 
Let SENS_VEL(j) represent the G_ROTATION, A_ACCELERATION, K_MATRIX, and TDLR_VELOCITY arrays with 
time history subscript (j), where j = 0, 1 , or 2. 

Let SENS_ALT(j) represent the K_ALT and AR_ALTITUDE arrays with time history subscript j, where j =0,1, or 2. 

Let f — att represent the function for derivative of attitude with respect to time. 

Let l_vel represent the function tor derivative of velocity with respect to time. 

Let f_alt represent the function for derivative of altitude with respect to time. 


Algorithm 

Do first estimates of changes using derivatives calculated at t2: 
kl = h x f_att (GP_ATTITUDE(2), SENS_ATT(2)) 

II = h x f_vel (GP_ATTITUDE(2), GP_VELOCITY(2), SENS_VEL(2)) 
m 1 = h x f_alt (GP_ATTITUDE(2), GP_VELOCITY(2), GP_ALTITUDE(2), SENS_ALT(2)) 


Do second estimates of changes using derivatives calculated at tl: 
k2 = h x f_att (GP_ATT1TUDE(2) + kl/2, SENS_ATT(1)) 

12 = hx f_vel (GP_ATTITUDE(2) + kl/2, GP_VELOCITY(2) + 11/2, SENS_VEL(1)) 

m2 = h x f_alt (GP_ATTITUDE(2) + kl/2, GP_VEL0C1TY(2) + 11/2, GP_ALT1TUDE(2) + in 1/2, SENS_ALT(1)) 

Do third estimates of changes using derivatives calculated at tl : 
k3 =hx f_alt (GP_ATTITUDE(2) + k2/2, SENS_ATT(1)) 

13 - h x f_vel (GP_ATT1TUDE(2) + k2/2, GP_VEL0C1TY(2) + 12/2, SENS_VEL(1)) 

tn3 = h x f_alt (GP_ATT1TUDE(2) + k2/2, GP_VELOCITY(2) + 12/2, GP_ALTITUDE(2) + tn2/2, SENS_ALT(1)) 

Do fourth estimates of changes using derivatives calculated at tO: 
k4 = h x f_att (GP_ATT1TUDE(2) + k3, SENS_ATT(0)) 

14 = h x f_vel (GP_ATTITUDE(2) + k3, GP_VEL0C1TY(2) + 13, SENS_VEL(0)) 

in4 = h x f_alt (GP_ATTITUDE(2) + k3, GP_VELOCITY(2) + 13, GP_ALTITUDE(2) + m3, SENS_ALT(0)) 


rp^ATTT S i° f f°^o c h A a Snli a !,“ t0 previous value of dependent variable to get current dependent variable: 
G1 _ATTITUDE(0) = GP_ATTITUDE(2) + 1/6 x (kl + 2 x (k2 + k3) + k4) 

GP_ VELOCITY (0) = GP_VELOCITY(2) + 1/6 x (II + 2 x (12 + 13) + 14 ) 

GP-ALTITUDE(O) = GP_ALTITUDE(2) + 1/6 x (ml + 2 x (m2 + m3) + m4) 


Action: Change Table of Contents (page vii) to reflect change in page number for the Bibliography from 
page 1 19 to page 123 0 r J 


Modified Text: BIBLIOGRAPHY 
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Support Documentation Change Report 


page 1 of 2 


1. Configuration Item 

Software Requirements GCS Development Specification 
Version 2.2 

2. Date 
January 19, 
1994 

3. Formal Modification #: 

2.2 - 28 

4. Part of Configuration Item Affected: 


INTRODUCTION, Subsection Exception Conditions, UPPER OR LOWER LIMIT EXCEEDED 
Table of Contents 

5. Reason for Modification: ” — — 


In the lequiiements for checking for upper or lower limit exceeded, specificity is needed regarding the data 
types of the elements to be checked, the context in which the checks should be made, and when the checks 
should be performed. 


6. Modification: 


\ctlon: Replace the entire paragraph under the heading "UPPER OR LOWER LIMIT EXCEEDED" 
new text. 


with the 


New Text: 

The current value for a data element exceeds its upper or lower limit as specified in the range section in the 
Data Requirements Dictionary Part I. 


Only certain data elements under 
which elements are to be checked 
is as follows: 


certain conditions are to be checked for limits exceeded. The criteria for 
, in what context they are to be checked, and when they must be checked 


Which data elements: 

A particular data element is to be checked for limits exceeded only if it is of data type REAL*8 and is in 

either of the two global data stores GUIDANCE_STATE or SENSOR_OUTPUT. 

Context for check: 

A data element is to be checked only when it is being used as an input. If the data element is a vector or 
array , then each element in the vector or array that is being used as input must be checked, including 
history values. It is not necessary for the functional unit CP to check any of its input data elements for 
limit exceeded. 

When data element must be checked: 

When an input data element is to be used or processed in a given subframe, then it must be checked 
sometime within that same subframe before it is used. If the data element is also being updated or 
changed in the same subframe befoie it is being used as an input, then it must be checked sometime 
between the time it is updated and the time it is used. 

7. SO A. Signature & Date: — — — __ ~ ' 

Original Signed by ■£"//& ^ 

George Finelli 
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Support Documentation Change Report Continuation 

page 2 of 2 

"a. Report#: 2.2-28 


b. Noles/Explanation (Please reference appropriate section number) 

Action: Change Table of Contents (page vi) to reflect change in page number for the section Output to be 
Generated for Each Exception Condition, from page 16 to page 17 

Modified Text: 

Output to be Generated for Each Exception Condition 17 



Support Documentation Change Report 




page 1 of ]__ 


1. Configuration Item 

Software Requirements GCS Development 
Specification Version 2.2 


2. Date 
March 15, 
1994 


3. Formal Modification #: 
2.2 - 29 


4. Part of Configuration Item Affected: 

Many miscellaneous parts are affected. 

(Each individual modification below lists the part affected by that modification) 


5. Reason for Modifications: ” 

Miscellaneous corrections, clarifications, and revisions 
(Each individual modilication below lists the reason for that modification) 


6. Modifications 
Modilication: 2.2-29.1: 

Part of Configuration Item Affected: Preface, first paragraph, last sentence 

Reason for Modification: Definition of "RTCA" has changed, and Guidelines DO-178B have 
replaced DO- 178 A 

Action: Change "Radio Technical Commission for Aeronautics RTCA/DO-178A " to 
"Requirements and Technical Concepts for Aviation RTCA/DO-178B" 

Modilication: 2.2-29.2: 

Part of Configuration Item Affected: Preface, second paragraph, first and second sentences and last 
paragraph, second sentence 

Reason for Modification: Guidelines DO-178B have replaced DO-178A 
Action: Change "DO-178A" to "DO-178B" 

Modification: 2.2-29:3: 

Part of Configuration Item Affected: BIBLIOGRAPHY, item [ 1 ] 

Reason for Modification: Definition of "RTCA" has changed, and Guidelines DO-178B have 
replaced DO- 178 A 

Action: Replace the current item with the new text below: 

New Text: 

[1] Special Committee 167 of Requirements and Technical Concepts for Aviation Inc. (RTCA, 
Inc.). Software Considerations in Airborne Systems and Equipment Certification 
DOCUMENT NO. RTCA/DO-178B. RTCA Inc., Washington, D. C„ 1992. 


7. SQA Signature & Date 


^Original Signed by 
-Kelly Hayhurst 


( dc Ix'ih) &/ ' y 

77 
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Report Continuation 

l a. Report #: Support Documentation Change Report 2.2-29 ~ ~ ^ ~ — — — 

b. Noles/Explanation (PJeasc reference appropriate section number) ~ ~ 

Modification: 2.2-29.4: 

Real™ 'r c, r d ; F ° REW0RD ' f " st P*™*™* second and third sciences 

Ktason lor Modification. Redundant information (see Appendix A) 

C *' OIF sp^dficUon'^ S “ ,enCC “ nd Change fi,S ‘ ‘ W ° WO,ds ofIhW sentence from "This 

Modification: 2.2-29.5: 

INTRODUCTION, second paragraph, .bird science 
tason tor Modification. The roll engines are on at the beginning of the trajectory 

tion. Change The axial and roll engines are ignited;" to "The axial engines ar e ignited;" 

Modification: 2.2-29.6: 

Parl ° f seme"c ' n " i0 " Ile,n AffedCd: INTRODUCTION, NOTATION, Ma.rices and Arrays, las, 

Reason for Modification: Clarification needed 

Action: Change the word "indices" to "index for the time history" 

Modification: 2.2-29.7 

Sl^ d - ;S rRODUCT,ON ’ REQUIREMENTS, Use of Tables , 

Reason for Modification: Clarification needed 
Action: Insert a new sentence between these two sentences 

Ncw r z ™ ° l ihe acii °" s » «*» 

Modification: 2.2-29.8: 

Part ofConfiguradon Iiem Affected: AECLP, P-Spee 2.3.1, COMPUTE LIMITING ERRORS 
Reason for Modification: Clarification needed 

10 iS " e8innh,S ° nht -1 * is the end of the 

New TexLwhere is the time at the beginning of this frame and t is the time at the end of this 

Modification: 2.2-29.9: 

Part ofC-nguration ftem Affected: AECLP, P-Spec 2.3.1, COMPUTE LIMITING ERRORS 
Reason for Modification: Clarification needed 

AC ' i0n S^;!’wr!h^^ e '° iS ,he be8inning ° f ““ ““ *P - ‘ is <i.e on,, of the 
New Text: where t 0 is the time at the beginning of this frame and t is the time at Ihe end of this 
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page 3 of 7 


a. Report #: Support Documentation Change Report 2.2-29 


b. Notes/Explanation (Please reference appropriate section number) 

Modification: 2.2-29.10: 

Part of Configuration Item Affected: AECLP, P-Spec 2.3.1, COMPUTE LIMITING ERRORS 
FOR THRUST, between the equation for TEJNTEGRAL and the sentence "Solve the 
following equation..." 

Reason for Modification: Clarification needed 

Action: Insert the new text 

New Text: where to is the time at the beginning of this frame and t is the time at the end of this 
frame. 

Modification: 2.2-29.11: 

Part of Configuration Item Affected: AECLP, P-Spec 2.3.1, Table 5.2 

Reason for Modification: Clarification needed 

Action: Insert the headings "CURRENT STATE" and "ACTIONS" 

Modification: 2.2-29.12: 

Part of Configuration Item Affected: AECLP, P-Spec 2.3.1, Table 5.3 

Reason for Modification: Clarification needed 

Action: Insert the headings "CURRENT STATE" and "ACTIONS" 

Modification: 2.2-29.13: 

Part of Configuration Item Affected: ASP, P-Spec 2.1.1, first paragraph, third sentence 

Reason for Modification: The part of the sentence following the comma is not necessary and is 
confusing. 

Action: Delete the part of the sentence following the comma, and change the comma to a period The 
new sentence is shown below: 

New lext: The sign ol the counter will always be positive, but the offset given in AJ3IAS will be 
negative or zero. 

Modification 2.2-29.14: 

Part of Configuration Item Affected: GP, P-Spec 2.2, subsection labeled DETERMINE IF 
ENGINES SHOULD BE ON OR OFF, first sentence 

Reason for Modification: FRAME_ENGINES_IGNITED could be initialized to some value other 
than zero if the initial FRAME_COUNTER is not initialized to the value one. 

Action: Delete the words "to zero" 

Modification 2.2-29.15: 

Part of Configuration Item Affected: GP, P-Spec 2.2, Table 5.9 

Reason for Modification: Clarification 

Action: In the heading over the fourth column, change "a prior frame?" to "any prior frame?" 
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Report Continuation 


page _4_ of _1 


■x. Report #: Support Documentation Change Report 2.2-29 


b. Notes/Explanation (Please reference appropriate section number) 

Modification 2.2-29.16: 

Part of Configuration Item Affected: GP, P-Spec 2.2, subsection labeled DETERMINE 
GUIDANCE PHASE, second paragraph, third sentence. 

Reason lor Modification: Inaccurate wording, and second double quote is in the wrong place 

Action: Change "PRESENT STATE" DESCRIPTION to "CURRENT STATE DESCRIPTION" 

Modification 2.2-29.17: 

Part of Configuration Item Affected: GSP, P-Spec 2.1.4, subsection labeled PROCESS table 
showing the map of G_COUNTER 

Reason for ^Modification: Numbering of the bit positions is not consistent with numbering in the 
V AX FORTRAN Language Reference Manual. 

Action: Change the numbering of die bits from 1 through 16 to 0 through 15. 

Modification 2.2-29.18: 

Part of S n SiJ[?ii r O" Item Affected: RECLP, P-Spec 2.3.2, subsection labeled DETERMINE 
PULSE INTENSITY AND DIRECTION, sixth sentence 

Reason for Modification: The word "step" has not been defined 
Action: Change the word "step" to the word "frame" 

Modification 2.2-29.19: 

Part of Configuration Item Affected: RECLP, subsection labeled DETERMINE ROLL ENGINE 

COMMAND, table showing the layout of pulse intensity and direction in the roll engine 
command b 

Reason for Modifmation: The numbering of the bit positions is not consistent with the numbering in 
the VAX FORTRAN Language Reference Manual. In addition, the format of the table is not 
consistent with the table in GSP, P-Spec 2.1.4 

Action: Change the numbering of the bits from 1 through 16 to 0 through 15, and move the bit 
positions to the top line and the layout to the bottom line. 

Modification: 2.2-29.20: 

Part of Configuration Item Affected: TDLRSP, P-Spec 2.1.3, Table 5.12 

Reason for Modification: Clarification needed 

Action: Insert the headings "CURRENT STATE" and "ACTIONS" 

Modification: 2.2-29.21: 

Part of Configuration Item Affected: DATA REQUIREMENTS DICTIONARY PART I element 
COMM_SYNC_PATTERN, subsection RANGE 

Reason for Modification: Clarification needed 

Action: Add the text "(binary)" 
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page _5_ of 7 


a. Report #: Support Documentation Change Report 2.2-29 


b. Notes/Explanation (Please reference appropriate section number) 

Modification: 2.2-29.22: 

Part of Configuration Item Affected: DATA REQUIREMENTS DICTIONARY, PART I, element 
REJSWITCH, subsection DATA STORE LOCATION 
Reason for Modification: Typographical Error 
Action: Change "GUIDANCE" to "GUIDANCEJSTATE" 

Modification: 2.2-29.23: 

Part of Configuration Item Affected: DATA REQUIREMENTS DICTIONARY, PART I element 
THETA, subsection DATA STORE LOCATION 

Reason for Modification: Typographical Error 
Action: Change "GUIDANCE" to "GUIDANCE_STATE" 

Modification: 2.2-29.24: 

Part of Configuration Item Affected: DATA REQUIREMENTS DICTIONARY PART III Table 
6.6 ’ ’ 

Reason for Modification: Typographical Error 

Action: Change "RE_SWTICH" to "RE_SWITCH" 

Modification: 2.2-29.25: 

Part of Configuration Item Affected: RECLP, P-Spec 2.3.2, Figure 5.2 

Reason for Modification: Ambiguity 

Action: Add the new text at the bottom of the figure. 

New Text: Note: Pi < P2 < P3 < P4 and 0] < 0 2 
Modification: 2.2-29.26: 

Part of Configuration Item Affected: TSP, P-Spec 2.1.5, Figure 5.4 

be redrawn M ° dification: Ambi g uit y regarding M3, M4, T3, and T4, and also the parabolas need to 

pa C rabolas Add ” eW ^ ^ ^ bott ° m of lhe figure conce ™ing M3, M4, T3, and T4, and also redraw the 
New Text: Note: M3<M4 and T3<T4 

Modification: 2.2-29.27: 

° f Configuration Item Affected: APPENDIX C. NUMERICAL INTEGRATION 
INSTRUCTIONS, ADAPTATION OF RUNGE-KUTTE FOURTH-ORDER METHOD FOR 
SIMULTANEOUS EQUATIONS TO THE GCS SOFTWARE 
Reason for Modification: Typographical errors 
Action: Change the following terms (everywhere they appear): 

from: xO, xl, yO, yl, tO, tl, t2, kl, k2, k3, k4, 11, 12, 13, 14, ml, m2, m3, m4 
to: x 0 , x,, y 0 , y,, t 0 , t, t 2 , k : , k 2 , k 3 , 1,, 1 2 , 1 3 I 4 m,, m 2 , m 3 m 4 

respectively. 
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Report Continuation 


page _6_ of _7_ 


a. Report #: Support Documentation Change Report 2.2-29 

Modification: 2.2-29.28: 

Part of Configuration Item Affected: Title Page 

Reasons for Modification: Version number of document needs to be updated. The RTCA document 
number and the names of the authors were missing. document 

Actions: Change the version number of the document from 2.2 to 2.3. Add the RTCA Document 
number and the names of the authors. document 

Modification: 2.2-29.29: 

Part of Configuration Item Affected: Page immediately following the title page 
Reason for Modification: Acknowledgement page was missing & 

Action: Insert acknowledgement page after the title page 

Modification: 2.2-29.30: 

Part of Configuration Item Affected: Appendix B, INTERFACE PROCESS seninn fii 
paragraph, last sentence, and CCS Initialization section, first senien'ce ' 

Reasons for Modifications: 

•The term "time step" has not been defined, and timing requirements have been removed 

•The initial value for SUBFRAME_COUNTER was omitted 
Actions: 

;“ CESS seclion ' cha "8 e lhc lext " lirae st ep" to "subframe”, and delete the text "or have run 

eounte? ^UBi^^M^^ronNTtrRt 111 ",fr, Cnd Pf ', he ‘l™ senU!nce ’ add lhe «« and the subframe 
countu (bUBFKAMh_COUNTER) will be initialized to the value one" 

| Modification: 2.2-29.31: 

rONTRn7^w 0 A n op e r Arfec ‘ ed: introduction, purpose of the guidance and 
CONTROL SOFTWARE, first sentence, and also the BIBLIOGRAPHY 

Reason for Modifications: Reference to the Viking 75 Spacecraft paper was omitted 

Vikin6 PUPe '' "’ e mTR0DUCn0N - and ontty f°f the 

Modification: 2.2-29.32: 

‘NTRODUCT.ON, GENERAL INFORMATION, 

Reason for Modifications: The terms i, j, and n are not defined 
Actions: Define the range for i and j, and change the range for k. 

Modification: 2.2-29.33: 

Part of Configuration Item Affected: Chapter 5, ARSP (P-Spec 2 1 2) Table 5 4 
Reason for Modifications: Heading in "Actions" columns is not consistent with other tables 
Action: Change "ACTIONS TO BE TAKEN" to "ACTIONS" 
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Modification: 2.2-29.34: 

Part of Configuration Item Affected: Chapter 5, CP (P-Spec 2.4), Table 5.5 

hSMrmKrvellicrf"" ' able iS '° be re “ d Cr ° SSWiSe ’ the in,emal lhles should be 

Actions: Replace the internal vertical lines, with horizontal lines 
Modification: 2.2-29.35: 

SPECTfcATON "“ n Item Alf “' C<l: APPENDIX A . NOTATION FOR LEVELS 0, I, AND 3 

Reason lor Moderations: Clariticaiion , more accorale wording, and addilional text is needed 
Actions: 

• In the first paragraph, last sentence, change the text "functional modules" to "processes" 

•In the second paragraph, first sentence, change the semicolons to commas, and change the word 
descriptions" to "specifications" b 

aid the externaL emifies"^ SentCnCe ’ change the texl " for lhe entire system" to "between the system 

•In the fourth paragraph, third sentence, change the text ";or," to ",or " 

•In the fourth paragraph, replace the fourth sentence with the text "The flow diagrams show what the 
piocess stiucture must do under all conditions." 

•In the fourth paragraph, next-to-last sentence, change the last word from "diagram" to "diagrams" 

•In the fifth paragraph, last sentence, change the word "when" to "under which", and add the text 
, and in some cases also contain output values for control signals" to the end of the sentence 

Modification: 2.2-29.36: 

Part of Configuration Item Affected: Entire specification 

Reason for Modification: Version 2.2 is to be replaced by Version 2.3 
Actions: 

•Renumber the pages in the entire document 

•Remove the notes "with mod 2.2-.." at the bottoms of the revised pages 
•Remove the bolding and the footnote numbers that had previously been added as a result of 

changing from Version 2.1 to Version 2.2 

* R vTrl e n v eCOnd SW ° f FOREWORD, which expained the differences between 

Version 2.1 and Version 2.2 of this specification. 

•Update the Table of Contents, List of Figures, and List of Tables to reflect the new page numbers 
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Support Documentation Change Report 


page 1 of_ 


1. Configuration Item 

Software Requirements GCS Development 
Specification Version 2.3 


2. Date 
May 12, 
1994 


3. Formal Modification #: 
2.3-1 


4. Part of Configuration Item Affected: 

Miscellaneous parts are affected. 

(Each individual modification below lists the part affected by that modification) 


5. Reason for Modifications: 

Miscellaneous clarifications and revisions. 

(Each individual modification below lists the reason for that modification) 


6. Modifications ~ 

Modification: 2.3-1. 1: 

Part of Configuration Item Affected: Chapter 1, INTRODUCTION, REQUIREMENTS Calls to 
GCS_SIM_RENDEZVOUS ’ 

Reason for Modification: Clarification. 

Action: Add new text at the end of the sentence 

New Text: See Chapter 2 and Appendix B for discussions regarding GCS_SIM_RENDEZVOUS. 


Modification: 2.3-1.2: 

Part of Configuration Item Affected: Chapter 1, INTRODUCTION, REQUIREMENTS, 

EXCEPTION HANDLING, Output to be Generated for Each Exception Condition Lower 
Limit Exceeded and Upper Limit Exceeded 

Reason for Modification: The only variables now being checked for limits exceeded are of type real 

Action: Delete the text "for type real elements, and use FORMAT (x,a32,i 1 2) for integer or logical 
data elements." b 


Modification: 2.3- 1.3: 

Part of Configuration Item Affected: Title Page 

Reason for Modification: Formal Modification Numbers are needed in addition to Version Number. 
Action: Add the Formal Modification Number 2.3-1 following the Version Number. 


7. SQA Signature & Date: 


Original Signed by 
.'Kelly Hayhurst 
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Support Documentation Change Report 


page 1 of 2_ 


1. Configuration Item 

Software Requirements GCS Development 
Specification Version 2.3 


2. Date 
May 18 
1994 


3. Formal Modification #: 
2.3-2 


4. Part of Configuration Item Affected: 

Miscellaneous parts are affected. 

(Each individual modification below lists the part affected by that modification) 


5. Reason for Modifications: — 

The scheduling of the GCS functional units and the termination conditions are being modified. 


6. Modifications " 

Modification: 2.3-2.1: 

Part of Configuration Item Affected: Chapter 4, SCHEDULING 

Reason for Modification: 'Hie scheduling of the functional units is being modified. The two major 
changes are that each functional unit will be executed every frame, and the check for 

subffame° n ^ ^ made at 1116 end °* the sub£rame instead of at the end of the second 
Action: Replace the entire section labeled SCHEDULING. 

Note: Even though this particular modification directly affects only the SCHEDULING section of 
Chapter 4 the changes made to this section do have an impact on the functional unit CP 
U'-spec 2 4) This is due to the fact that each functional unit will now be scheduled everv 
frame, and therefore the data which must be sent by CP in some subframes will be different 
trom what it was when not every functional unit was being scheduled every frame. 

Modification: 2.3-2.2: 

Part of Configuration Item Affected: Chapter 5, ARSP - Altimeter Radar Sensor Processing 

ALTERNATE PROCESSING IF THIS IS AN 

Reason for Modification: The actual calculations for this functional unit are to be performed each 

Action: Delete the entire section. 


7. SQA Signature & Date: 


v Original Signed by 
-Kelly Hayhurst 
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Support Documentation Change Report Continuation 

page _2_ of _2_ 


a. Report #: Support Documentation Change Report 2.3-2 

b. Notes/Explanation (Please reference appropriate section number) 


Modification: 2.3-2.3: 

Part of Configuration Item Affected: Chapter 5, TDLRSP —Touch Down Landing Radar Sensor 
Processing (P-Spec 2.1.3), Section labeled 'PERFORM ALTERNATE PROCESSING IF 
THIS IS AN EVEN-NUMBERED FRAME" 

Reason for Modification: The actual calculations for this functional unit are to be performed each 
frame. 

Action: Delete the entire section. 

Modification: 2.3-2.4: 

Part of Configuration Item Affected: Chapter 5, CP - Communications Processing (P-Spec 2 4) 

section labeled PREPARE SAMPLE MASK, third sentence. 

Reason for Modification: The scheduling changes in Formal Modifications 2.3-2.2, and 2.3-2.3 

require that the calculations for functional units ARSP and TDLRSP be performed every frame, 
and since the outputs may change every frame, they should be sent every frame. 

Action. Delete the third sentence which states "The output variables from the functional units ARSP 
and TDLRSP, however, should not be transmitted when the variable FRAME_COUNTER is 
an even number." 

Modification: 2.3-2.5: 

Part of Configuration Item Affected: Title Page 

Reason for Modification: Formal Modification Numbers are needed in addition to Version Number. 
Action: Add the Formal Modification Number 2.3-2 following the Version Number. 
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Support Documentation Change Report 


page 1 of 2_ 


1. Configuration Item 

Software Requirements GCS Development 
Specification Version 2.3 


2. Date 
June 8, 1994 


3. Formal Modification #: 
2.3-3 


4. Part of Configuration Item Affected: 

Several miscellaneous parts are affected. 

(Each individual modification below lists the part affected by that modification) 


5. Reasons for Modifications 

Miscellaneous corrections and clarifications. 

(Each individual modification below lists the reason for that modification) 


6. Modifications 
Modification: 2.3-3.1 

Part of Configuration Item Affected: INTRODUCTION, EXCEPTION HANDLING Exception 
Conditions, UPPER OR LOWER LIMIT EXCEEDED, Context for Check 

Reason for Modification: A clarification is required for the context in which a limit check should be 
made. 

Action: Insert new text between the first and second sentences. 

New lext: Rotation of a data element is not considered to be a use as an input for the purposes of 
limit checking. 

Modification: 2.3-3.2 

Part of Configuration Item Affected: Chapter 5, AECLP, P-Spec 2.3.1, INPUT Table. 

Reason lor Modification: Any variable which must be accessed in order to perform the functions of a 
functional unit should be listed in the INPUT Table for that functional unit, but the variable 
INTERNAL_CMD is not listed in the INPUT Table. 

Action: Add the variable INTERNAL_CMD to the INPUT Table. 

Modification: 2.3-3.3 

Part of Configuration Item Affected: Chapter 5, ARSP, P-Spec 2.1.2, PROCESS section, first 
paragraph. 

Reason for Modification: This paragraph should have been deleted by Formal Modification 2.3-2, in 
which it was stated that this functional unit should be executed every frame. 

Action: Delete the entire paragraph. 


7. SQA Signature & Date: 


Original Signed by 
Kelly Hayhurst 
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Support Documentation Change Report Continuation 


page _2_ of 2 


a. Report #: Support Documentation Change Report 2.3-3 


b. Notes/Explanation (Please reference appropriate section number) 

Modification: 2.3-3.4 

paragrJph° nngUrati ° n ItCm Attectcd: Cha P ler 5 > TDLRSP, P-Spec 2.1.3, PROCESS section, first 

Reason lor Modification: This paragraph should have been deleted by Formal Modification 2.3-2 
winch it was stated that this functional unit should be executed every frame. 

Action: Delete the entire paragraph. 


m 


Modification: 2.3-3.5 

Part of Configuration Item Affected: Chapter 5, CP, P-Spec 2.4, INPUT Table. 

Reason lor Modification: Any variable which must be accessed in order to perform the functions of a 

r'^TATiiQ 01 S 10 r d b ? . lsl f d 111 tbc INPbJT Table for that functional unit, but the variable 
C_STATUS is not listed in the INPUT Table. 

Action: Add the variable C_STATUS to the INPUT Table. 

Modification: 2.3-3.6 

Part of Configuration Item Affected: Chapter 5, CP, P-Spec 2.4, PREPARE SAMPLE MASK 
second and third sentences, and PREPARE DATA, second sentence. 

Reason for Modification: In PREPARE SAMPLE MASK, an exception needs to be added to the 

PRFPARF n ATA 1 n lhlrd sen , tence needs more c,arit y’ and lhe fourth sentence is unecessary. In 
PREPARE DATA, the second sentence is redundant. J 

Action: In PREPARE SAMPLE MASK, replace the second and third sentences with the new text and 
delete the fourth sentence. In PREPARE DATA, delete the second sentence. 

Sid hf nS liS ! ed il J Table 5 5 tbat ma y have changed during the present subframe 
should be marked in the mask and transmitted, with one exception. The variable TE_INTEGRAL mav 

TF C iNTPrDA? P ' 3n 1 m K SeCOnd s . ubframe and b y AECLP in the third subframe; however, Y 

«.mf INTEG i R o L shoilld be tr ^mitted by CP only during the third subframe, and not during the second 

obiect^scahr ° f ^ blSt ? y vanabl, f> tha t is. one which contains a time dimension, only the 

object (scalar, vectoi, oi anay) with a time subscript of zero should be transmitted. 

Modification: 2.3-3.7 

Part of Configuration Item Affected: Title Page 

Reason for Modification: Formal Modification Numbers are needed in addition to Version Number 
Action: Add the Formal Modification Number 2.3-3 following the Version Number. 
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Support Documentation Change Report 


page 1 of 2 


1 1. Configuration Item 

2. Date 

3. Formal Modification #: 

( Software Requirements GCS Development 

23 ' 

2.3-4 

i Specification Version 2.3 


4. Part of Configuration Item Affected: 


Miscellaneous parts are affected. 

(Each individual modification below lists the part affected by that modification) 

5. Reason for Modifications: 

Miscellaneous corrections and clarifications. 

(Each individual modification below lists the reason for the modification) 


6. Modifications ~ ~ 

Modification: 2.3-4.1 

Part of Configuration Item Affected: TABLE OF CONTENTS and INTRODUCTION 
REQUIREMENTS 

Reason for Modification: There is no explicit statement regarding the required precision for floating 
point calculations. 

Action: In the INTRODUCTION, add a subsection containing an explicit precision requirement for 
floating point calculations, and add this subsection name to the TABLE OF CONTENTS. 

Modification: 2.3-4.2 

Part of Configuration Item Affected: Chapter 5, ASP (P-Spec 2.1.1), section labeled 'DETERMINE 

ACCELERATIONS AND ACCELEROMETER STATUS" 

Reason for Modification: The form of the equation given for the standard deviation, if implemented 
exactly as shown, may result in a negative argument for the square root due to roundoff. 

Action: Change the form of the equation for the standard deviation to one which, if implemented 
exactly as shown, cannot lead to a negative argument for the square root. 

Modification: 2.3-4.3 

Part of Configuration Item Affected: Chapter 6, PART I, DATA ELEMENT DESCRIPTIONS, 
element AE_TEMP 

Reason for Modification: AE_TEMP has three valid values, and thus a data type of integer*2 would 
be more appropriate than one of logical* 1 . 

Action: Change the data type of AE_TEMP from logical* 1 to integer*2. 

Note: Even though this change is being made directly only to the Data Dictionary, it does have an 

impact on the packing of data for the third subframe into the PACKET array. 

7. SQA Signature & Date: ^ . 

Original Signed by 

■ Kelly Hayhurst 
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Support Documentation Change Report Continuation 


page 2 of 2 

a. Report #: Support Documentation Change Report 2.3-4 ~~ -~== 

b. Notes/Explanation (Please reference appropriate section number) 

Modification: 2.3-4.4 

Part of Configuration Item Affected: Chapter 6: PART I, DATA ELEMENT DESCRIPTIONS, 
element CHUTE_RELEASED; PART II, CONTENTS OF DATA STORES, Table 6.1 and 
Table 6.2 

Reason for Modification: CHUTE.RELEASED is in the GUBD AN CE_STATE store, but its value is 
transmitted to the external world, and thus it should be in the EXTERNAL store. 

Action: In PART I, under CHUTE_RELEASED, change the DATA STORE LOCATION from 

GUID AN CE_S TATE to EXTERNAL. In PART H, delete CHUTE_RELEASED from Table 
6.1, and add CHUTE_RELEASED to Table 6.2. 

Modification: 2.3-3.5 

Part of Configuration Item Affected: Title Page 

Reason for Modification: Formal Modification Numbers are needed in addition to Version Number. 

Action: Add the Formal Modification Number 2.3-4 following the Version Number. 




Support Documentation Change Report 


page 1 of 4 


1. Configuration Item 

Software Requirements GCS Development 
Specification Version 2.3 

2. Date 

September 

,aCl994 

3. Formal Modification #: 
2.3-5 

4. Part of Configuration Item Affected: 




Miscellaneous parts are affected. 

(Each individual modification below lists the part affected by that modification) 
5. Reason for Modifications: 

Miscellaneous corrections and clarifications. 

(Each individual modification below lists the reason for the modification) 


6. Modifications 

Modification: 2.3-5.1 

Part of Configuration Item Affected: INTRODUCTION, Figures 1.1, 1.2, and 1.3 

Reason for Modification: The vehicle axes should form a right-handed coordinate system, but are 
not shown as such. 

Action: In Figure 1.1, change the direction of the positive Y axis. In Figure 1.2, change the direction 
of the positive Y and the positive Z axes, and enhance the phase descriptions. In Figure 1.3: 
in the "Bottom View", reverse the direction of the positive Y axis and of the positive roll; in 
the "Side View" on the left-hand bottom of the page, reverse the direction of the positive Y 
axis and of the positive yaw; in the "Side View" on the right-hand bottom of the page, change 
the note to show that the positive Y axis comes out of the page. 

Modification: 2.3-5.2 

Part of Configuration Item Affected: Chapter 5, ARSP (P-Spec 2.1.2), input table. 

Reason for Modification: The variable FRAME_COUNTER'is not an input to this functional unit. 

Action: Delete the variable FRAME_COUNTER from the input table. 

Modification: 2.3-S.3: 

Part of Configuration Item Affected: Chapter 5, ASP (P-Spec 2.1.1), input table 

Reason for Modification: The variables are not listed in ASCII order. 

Action: Arrange the variables in the input table in ascending ASCII sequence. 


7. SQA Signature & Date 


* Original Signed by 
Kelly Hayhurst 
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Support Documentation Change Report Continuation 

— 5 77 page _2_ °f _4_ 

a. Report #: Support Documentation Change Report 2.3-5 

b. Notes/Explanation (Please reference appropriate section number) 

Modification: 2.3-S.4: 

Part of Configuration Item Affected: Chapter 5, GP (P-Spec 2.2), input table 
Reason for Modification: The variables are not listed in ASCII order. 

Action: Arrange the variables in the input table in ascending ASCII sequence. 

Modification: 2.3-5.5: 

Part of Configuration Item Affected: Chapter 5, GP (P-Soec 2 2) section labeled 'TAT m atc 
NEW VALUES OF ATTITUDE. vfixJOIY. 

Reason^forModification : The equations for rate of change of attitude, velocity, and altitude need 
Action: Replace Table 5.8 and most of the text in this section. 

Modification: 2.3-S.6: 

vSocS^Or" “ iL ChaP,er 5 ’ GP (P ' SpeC 2 - 2)l SeCti ° n labeled "DETERMINE 

Reason for Modification: Some of the wording in this section needs improvement, and in addition, it 
has “ ot be en made clear that the velocity being considered is the x component of the velocity 

;^ Se , Cti ° n DETE RMINE VELOCITY ERROR, replace most of the text, and also add a 
statement concerning the minimum numher of non-zero elements in CONTOUR ALTITUDE 

^ label ° n u the X_a ? is md on the Rectories, add a label for the constant- 
vel^ity part of the contour, and change the curves to make them distinguishable from each 

Modification: 2.3-S.7: 

Part Chapter 5, GP (P-Spec 2.2), section heading "DETERMINE 

Reason for Modification: All section headings should be in bold print. 

Action: Change the heading to bold print. 

Modification: 2.3-5. 8: 

Part ° f Wf^fr^PT°nR t roi i ^TOrff ( T : A C ifPff n 5 ’ GP (P ' S P ec 2 - 2 )’ section labeled "DETERMINE 
WHICH SET OF CONTROL LAW PARAMETERS TO USE", second paragraph, seventh 

sentence, beginning with "The constant-velocity part of the contour " 

Reasonjor Modification: The explanation for the constant-velocity part of the contour needs 

Action: Change the wording of this sentence. 

! Modification: 2.3-S.9: 

Part ofCoi^gurafion Item Affected: Chapter 5, GSP (P-Spec 2.1.4), section labeled "PURPOSE", 

Reason for Modification: The sentence states "as shown", but there is no figure 
Action: Delete the text "as shown". 
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Support Documentation Change Report Continuation 

a. Report #: Support Documentation Change Report 2 . 3-5 — 6 ~ ° f ~ 

~b. Notes/Explanation (Please reference appropriate section number) 

| Modification: 2.3-5.10: 

Part of Configuration Item Affected: Chapter 5 , RECLP IP-Snec 9 9 ftpttrt. ^ o 
Re ^ 0 n dSn diflCati0n: Th£re iS n ° Statement re § ardin 8 viewing reference for 'the roll thrust 

ACti ° n ^r at me b °“ 0m ° f FigUre 5 ' 2 regardin 8 ** ^nce for the roll thrust 

| Modification: 2.3-5.11 

Part ° f v m°Kj!S , 4S" ,ed! Chapter 5 ' TOLRSP (p ‘ Spec 2 - 1 - 3) - section labcled "SET 

! Modification: 2.3-5.12 

Reason Chap “ r * TOSP (P - Sprc 21 ®. input and output tables 

ason tor Modification. The variables are not listed in ASCII order. 

ction: Arrange the variables in the input and output tables in ascending ASCII sequence. 

| Modification: 2.3-5.13 

Par ‘ °^ek^^ l ATMOSPFER^ C 'TT?Mp baptar 1 DATA ELEMENT DESCRIPTIONS, 

ement A 1 MOSPHERICJIEMP, section DATA STORE LOCATION. 

eason or Modification: does not belong at the end of the DATA STORE LOCATION 

Action: Remove the at the end of the DATA STORE LOCATION. 

| Modification: 2.3-5.14 

Reason for Modiflcation: The DATA STORE LOCATION is not correct 
Actton: Change the DATA STORE LOCATION from GUIDANCE to GUIDANCE.STATE. 

| Modification: 2.3-5.15 

Part of Configuration Item Affected: Chapter 6 , PART I, DATA ELEMENT df^pr tpttomc 
element GP_ROTATION, section DATA STORE LOCjATON ^ DESCRIPTI0NS - 

Reason for Modification: " does not belong at the end of the DATA STORE LOCATION 
Action. Remove the at the end of the DATA STORE LOCATION. 

I Modification: 2.3-5.16 

Par ‘ 6 - PART 1 DATA ELEMEN T DESCRIPTIONS, 

AcTn: Re“tSc“. S ** ^ C “>"' 
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Report Continuation 

page 4 of 4 

a. Report #: Support Documentation Change Report 2.3-5 ' “ 

b. Notes/Explanation (Please reference appropriate section number) 

Modification: 2.3-5.17 

Part of Configuration Item Affected: Chapter 6, PART I, DATA ELEMENT DESCRIPTIONS 
element TE_LIMIT, ATTRIBUTE section. 

Reason for Modification: Consistency of notation. 

Action: Change "Data" to "data". 

Modification: 2.3-5.18 

Part of Configuration Item Affected: Title Page 

Reason for Modification: Formal Modification Numbers are needed in addition to Version Number 
Action: Add the Formal Modification Number 2.3-5 following the Version Number. 
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page 1 of 2 


1 1. Configuration Item 

2. Date 

3. Formal Modification#: 

Software Requirements GCS Development 
1 Specification Version 2.3 

December 
21, 1994 

2.3-6 


4. Part of Configuration Item Affected: 


Miscellaneous parts are affected. 

(Each individual modification below lists the part affected by that modification) 

5. Reason for Modifications: 

The Preface needs to be updated, and the calculation of the checksum in the communications 
functional unit needs additional requirements. 


6. Modifications 
Modification: 2.3-6.1 

Part of Configuration Item Affected: TABLE OF CONTENTS 
Reason for Modification: A new appendix , namely Appendix D, is needed. 
Action: Add Appendix D to the TABLE OF CONTENTS. 

Modification: 2.3-6.2 

Part of Configuration Item Affected: LIST OF TABLES 
Reason for Modification: TABLE 5.7 was renamed. 

Action: Change name of TABLE 5.7 in LIST OF TABLES. 

Modification: 2.3-6.3 

Part of Configuration Item Affected: CP, Section labeled "PROCESS" 
Reason for Modification: The term "message" needs to be defined. 

Action: Replace the first sentence of this section. 


Modification: 2.3-6.4 

Part of Configuration Item Affected: CP, Section labeled "CALCULATE CHECKSUM" 

Reason for Modification: Clarification is needed, and a reference is needed to point to the new 
Appendix D. 

Actions: Replace the first paragraph of this section, rename and replace TABLE 5.7 with a table that 
includes the byte allocations for each subframe, and delete the first part of the note under 
TABLE 5.7. 


7. SQA Signature & Date: 


Original Signed by 
-Kelly Hayhurst 
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b. Notes/Explanation (Please reference appropriate section number) 

Modification: 2.3-6.5 

Part of Configuration Item Affected: Between Appendix C and the Bibliography. 

Reason for Modification: Appendix D is needed. y 

Action: Add Appendix D. 

Modification: 2.3-6.6 

Part of Configuration Item Affected: Title Page 

s," in “ » ^ *<“>>«. 

lhie^RTCA^l^-n^^Docui^Mt^umber 1 ^" 61 ^ ^ f0U ° Wing VerSi0 " “ d <“•“ 

Modification: 2.3-6.7 

Part of Configuration Item Affected: Preface 

Reason for Modification: The preface needs to be updated to be consistent with RTCA/DO-178B 
Action: Replace the entire preface. 

Modification: 2.3-6.8 

Part of Configuration Item Affected: Bibliography 

refMeiKes^^^e^ne^p^ace^ 16 W0 ^ ” ** biWiograph >' “* not » ith *= 

Action: Reverse the positions of the first two items in the bibliography. 



Support Documentation Change Report 


1 1. Configuration Item 

Software Requirements GCS Development 
Specification Version 2.2 


2. Date 
March 14, 
1995 


page 1 of 2_ 

3. Formal Modification #: 
2.3-7 


4. Part of Configuration Item Affected: 

Chapter 5, ASP (P-Spec 2.1.1); Chapter 5, GP (P-Spec 2.2); Title Page 


5. Reason for Modifications: 

Each individual modification below lists the reason for that modification 


6. Modifications 
Modification: 2.3-7.1: 

Part of Configuration Item Affected: Chapter 5, ASP (P-Spec 2.1.1), section labeled "DETERMINE 
ACCELERATIONS AND ACCELEROMETER STATUS" 

Reason for Modification: When all three previous values of A_STATUS are healthy and all three 
previous values of A_ACCELERATION are equal to each other, it is not necessary to check 
for extreme values of acceleration. 

Action: Under the sentence "the following steps are described for the x axis but should be performed 
for each axis:", a new condition was added as the second condition and the last condition was 
modified. 

Modification: 2.3-7.2: 

Part of Configuration Item Affected: Chapter 5, GP (P-Spec 2.2), Table 5.9 

Reason for Modification: In the heading of the third column under "CURRENT STATE", eliminate 
the possibility of the argument of the square root function being negative, and eliminate any 
ambiguity from the fact that parentheses are not used. 

Action: Instead of using GP_ALT1TUDE as the argument for the square root, the maximum of the 
two values, namely GP_ALTITUDE and zero, is to be used. Parentheses were also added. It 
was also necessary to add a footnote below the table because the new square root argument no 
longer fits in the table cell. 


7. SQA Signature & Date: j - 

& Original Signed by 3 

Kelly Hayhurst 
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b. Notes/Explanation (Please reference appropriate section number) 

Modification: 2.3-7., 3: 

Par ‘ S^Tabfei'l'a SeC,i ° n labeled " DETERMINE 

ReaSOn to r c““t"“gtgat[ve b0th P ' aCeS ’ eUmina ' e 11,6 P ° SSibiIity ° f 1116 ar 8 umem ° f ™>t 

ACtt ° n: ' 'CUR a R b R^° ™ 4 e ,' EV ENT'; column i,, the flrst line where ^ column GP _ PHASE unte 

- , contains 3 (fourth row of table), in order to avoid the possibility of the 

GP r00t fun l ti0n b ! in f negative ’ the maximum of the two Values, namely 

, ^-^TTrUDE and zero, is to be used. It was necessary to add a footnote below the table ^ 

SqU T root argument would no longer fit in the table. It was also necessary to 
make the same change to the same expression under the bullet labeled "PHASE 3". 

Modification: 2.3-7 A 

Part of Configuration Item Affected: Title Page 

Reason tor Modification: Formal Modification Numbers are needed in addition to the Version 
Number, and the date needs to be updated. version 

ACti ° n! (tote d the F0Imal Modifkaaon Number 2 - 3 ' 7 following the Version Number, and update the 
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Support Documentation Change Report 


page 1 of 1 

2. Dale: 

8/25/94 

4. Pari of Configuration Item Affceted: 

All AECLP Expected Values files (AECLP*.EX), The RUN_PARAMETERS namelist 

5. Reason for Modification: 

Creating new expected results files which will be able to compare till of the namelisls, including the RUN_PARAMETERS. 


6. Modification: 

Creating new expected results files which will be able to compare all of the namelists, including the RUN _PARAMETERS. 


Original Signed by 
'Kelly Hayhurst 




3. Formal Modification it: 1 


1. Configuration Item: 
Software Verification Cases 
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Support Documentation Change Report 


1. Configuration Item: 
Software Verification Cases 


2. Dale: 
8/25/94 


page 1 of 1 

3. Formal Modification ft: 2 


4. Part of Configuration Item Affected: 

All CRCP Expected Values files (CRCP*.EX), The RUN_PARAMETERS namelist 


5. Reason for Modification: 

Creating new expected results files which will be able to compare all of the namelists, including the RUN.PARAMETERS. 


6. Modification: 

Creating new expected results files which will be able to compare all of the namelists, including the RUN_PARAMETERS. 


7. SQ A Signature & Date: Original Signed by 

i — Kelly Hayhurst 


G/30 
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Support Documentation Change Report 


page 1 of 1 


1. Configuration Item: 

2. Date: 

3. Formal Modification #: 3 

Software Verification Cases 

9/7/94 


4. Part of Configuration Item Affected: 

All GP Tcstcases and Expected Values files 




5. Reason for Modification: 


The value for FRAME_ENGINES_IGNITED was set incorrectly in the input files. 


6. Modification: 

Pul in the correct value for FRAME_ENGINES JGNITED for all test cases, reran the Mathematica model and replaced all the 
test cases and expected results files associated with GP. 


7. SQA Signature & Date: 0rjginal signed by 
Kelly Hayhurst 
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page 1 of 1 

1. Configuration Item: 

2. Date: 

3. Formal Modification #: 4 

Soli ware Verification Cases 

9/19/94 

4. Part of Configuration Item Affected: 

All GP Testcases and Expected Values Files 



5. Reason for Modification: 




Due to Spec Mod 23-4 A all test cases must be recreated in order to put CHUTE_RELEASED into the correct data store 
(EXTERNAL) and remove it from GUIDANCEjSTATE. 


6. Modification: 

CHUTE_RELEASED was placed in the correct data store namelist in all test cases. 


7. SQA Signature & Date: _ . . , 

, On ginal Signed by 

Kelly Hayhurst 
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Support Documentation Change Report 


page 1 of 1 


1. Configuration Item: 

2. Date: 

3. Formal Modification #: 6 

Software Verification Cases 

9/19/94 


4. Part of Configuration Item Affected: 



All RECLP Testcases and Expected Values files 



5. Reason for Modification: 


Due to Spec Mod 23-4.4 all test cases must be recreated in order to put CHUTE_RELEASED into the correct data store 
(EXTERNAL) and remove it from GUIDANCE_STATE. 


6. Modification: 

CHUTE_RELEASED was placed in the correct data store namelist in all testcases. 


7. SQA Signature & Date: original signed by 

Kelly Hayhurst 
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1 . Configuration Item: 

2. Date: 

3. Formal Modification #: 

CP Test Cases 

12- 21-94 

8 


4. Part of Configuration Item Affected: 

Expected values files for CP test cases and CP model. 


5. Reason for Modification: 

The Packet processing for CP has been updated in the GCS Specification. The CP model must now be updated to match the Spec. 
The expected results must also be regenerated using the updated model. 


6. Modification: 


The model of CP has been updated so that the bit checksum bytes do not switch positions before being stored into the packet. The 
expected values files have been regenerated using the updated model. 


7. SQA Signature & Date: 0rigina , sjgned by 
Kelly Hayhurst 
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1 . Configuration Item: 

ASP Test Cases 

4. Part of Configuration Item Affected: 
ASP test cases and expected values files. 


page 1 of. 

2. Date: 3. Formal Modification U: 

12- 28-94 9 


5. Reason for Modification: ™ ™~ 

ThC „ A * S L RcquirCmentS bascd tesl cases tesl lhc wron 8 sUltus variable. This directly effects 6 ASP test cases but should be corrected 
in all ASP test cases. 


6. Modification: ~ 

AH ASP test cases have been corrected to test the A_STATUS variable instead of AR_STATUS variable. The updated test cases 
have been re-executed with the VENUS prototype and no ".ANA" files were generated indicating that all expected values files 
match the prototype results. 


7. SQA Signature & Date: 
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1. Configuration Item: 

2. Date: 

3. Formal Modification U: 

CP Model & CP Test Cases Expected Values Files 

1-9-95 

10 

4. Part of Configuration Item Affected: 

Expected values files for CP test cases and CP model. 



5. Reason for Modification: 




An error has been found in the CP test case expected values files. This error can be traced to modifications for SDCR-8 during 
which the CP model was modified and verified against the VENUS prototype. During that verification, necessary VENUS switches 
were not set causing no CRC checksum to be generated. The checksum needs to be added back to the PACKET variable in the 
expected values files 


6. Modification: 

The model of CP has been updated so that the bit checksum bytes are being stored into the packet. The expected values files have 
been regenerated using the updated model. 


7. 


SQA Signature & Dale: 
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1. Configuration Item: 

Verification Cases - Test Drivers 

4. Part of Configuration Item Affected: 

Subframe and frame test drivers calculate the expected value of the PACKET data clement. The subroutine that performs this 
calculation is P_EX_CP.FOR for the Pluto and Mercury implementation respectively. 


2. Date: 3. Formal Modification U: 

2-6-95 11 


5. Reason for Modification: ~~ 

The subroutine for generating expected values for subframe and frame test cases use a duplicate of the CP model. This part was not 
updated when the Specification for CP was updated in formal mod # 2.3-6. The subroutines need to be modified so that the bit 
checksum is no longer flipped. 


6. Modification: 

In the file P_EX_CP .FOR the three instances of code which reverses the CRC byte has been commented out. The CRC byte is no 
longer flipped for any subframe packet. 
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1 . Configuration Item: 

2. Date: 

3. Formal Modification #: 

Verification Cases - Subframe Test Cases 

2-7-95 

12 

4. Part of Configuration Item Affected: 

GPSF.OOl to 008.TC, GPSF_001 to 008.EX, and CLP_01 l.TC, and CLP_01 l.EX 


5. Reason for Modification: 




The subframe counter value in the above test cases does not agree with the subframe being tested. This effects the generation of 
values for the PACKET data element during CP processing at llie end of the subframe. 


6. Modification: 


The test case input and expected values files were edited instead of regenerated because only one item was changed and no 
calculations were involved. The subframe counter has been updated to 3 in the CLP_01 l.TC. The CLP_01 1.EX had the correct 
value for subframe counter so no editing was required. The subframe counter has been set to 2 for GP subframe test cases 
GPSF_001 to 008.TC and GPSF.001 to 008.EX. 
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b Original Signed by 
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1. Configuration Iicm: 2. Date: 3. Formal Modification #: 

Verification Cases - Frame Test Cases 2-15-95 14 

4. Part of Configuration Item Affected: 

FRAME_001-009.TC and FRAME_001-009.EX. Also affected are lest drivers for each implementations. These are 
P_TEST_FRAME.FOR and M_TEST_FRAME.FOR 

5. Reason for Modification: 

Local variable names in the frame model were miss-matched for GP_ALTITUDE. This caused the expected value of the 
GP_ALTITUDE history index to be incorrect. 


6. Modification: 

Test case FRAME001 to FRAME_008 were regenerated witlt the model of GP fetched from CMS. No changes were made to the 
GP model. The drivers were corrected so that lire functional units arc not called when GP_PHASE is 5. 
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1. Configuration Item: 

2. Date: 

3. Formal Modification U: 

Verification Cases - Models 

2-23-95 

15 


4. Part of Configuration Item Affected: 

The model for generating expected values for GP test cases and all test cases that use the model. This includes die test GP 
functional unit test cases, the GP subframe test cases, the Frame lest cases. 


5. Reason for Modification: 

The model for GP test cases docs not transition from phase 4 to phase 5 correctly for when TDS_STATUS is FAILED and 
TD_SENSED is TOUCH_DOWN_NOT_SENSED. 


6. Modification: 

The model for GP has been corrected by removing the extra conditions in the statements the perform the GP_PHASE transition. All 
the GP related test cases have been regenerated. 


7. SQA Signature & Dale: ~ ,, 

Original Signed by 
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1. Configuration Iicm: 

Verification Cases - Models 

4. Part of Configuration Item Affected: 

The GP sirucuiral lest cases for Mercury, the expected values and the malhcmatica driver files . 


2. Date: 3. Formal Modification tt: 

2-24-95 16 


5. Reason for Modification: 

The model for GP lest cases did not transition from phase 4 to phase 5 correctly for when TDS_STATUS is FAILED and 
TD_SENSED is TOUCH_DOWN_NOT_SENSED -- and was corrected as per SDCR #15. The corresponding corrections need to 
be made for the Mercury structural test cases. The driver files need to be replaced to reflect changes in names of the malhcmatica 


6. Modification: - - „ ~ 

The test cases and expected values were recreated due to a change in the malhcmatica code (see SDCR 15). The driver files 
changed llie actual code name of GP.TC.CODE to GP.M to reflect the names of the code saved in CMS. 


— i 

7. SQA Signature & Date: _ . . , 
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Configuration Item: 

-rification Cases -Malhematica Drivers 

1 

2. Date: 
2-24-95 

3. Formal Modification U: 
17 

4. Part of Configuration Item Affected: 

The Malhematica drivers for the structural test cases for AECLP and RECLP (M_RUN 

_AECLP_ST.*, M_RUN_RECLP_ST.*) 


5. Reason for Modification: 

The driver files need to be replaced to reflect changes in names of the malhematica files. 


6. Modification: 

The driver files changed the actual code name of AECLP.TC.CODE to AECLP.M and RECLP.TC.CODE to RECLP.M to reflect 
die names of the code saved in CMS. 


■ / 
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1. Configuration Item: Verification Cases 2. Date: 

(Frame and Subframe Command files 2/25/95 


page 1 of 1 


3. Formal Modification #: 18 


4. Part of Configuration Item Affected: GP Functional unit Test Cases, GP Subframe Test cases, GP Structural Test Cases 
NAMELIST EX 


5. Reason for Modification: 

When these files were recreated (SDCR 15) an old version of the namelist code was used. This code causes a problem when the 
values of G_ROTATION arc negative. This only affects a few test cases, but all test cases should be recreated and rerun. In a 
FORTRAN namelist file anything in the 1st column is ignored. 


6. Modification: 

The modification was made to the file NAMELIST_EX which creates die expected values files. Spaces were added before the 
data was written to the file. The lest cases were then rerun. 


7. SQA Signature & Dale: ori?ina| signed by 
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1. Configuration Item: 

2. Date: 

3. Formal Modification tk 

Verification Cases 

3/1/95 

19 

4. Part of Configuration Item Affected: 

Structural test cases for GP for die Mercury implementation 




5. Reason for Modification: 

The structural test cases for GP should have been reserved and changed under SDCR 18; however, due to an oversight, those test 
cases were not reserved. Those test cases still need to modified as described in SDCR 18. 


6. Modification: 

The modification was made to the NAMELIST_EX which creates the expected value files. Spaces were added before llic data was 
written to the file. 


7. SQA Signature 4 Date; 0rigina| ^ ^ / 
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1. Configuration Item: 

Verification Cases 

4. Part of Configuration Item Affected: 

The GP subframe expected values files and the GP subframe mathemalica run files. 


2. Date: 3. Formal Modification U: 

3/1/95 20 


5. Reason for Modification: 

The changes made in SDCR 18 were implemented incorrectly due to an error in the run files. The expected values data did not 
have the prefix EX_ in front of the variable names. 


6. Modification: - 

Modification was made in the RUN_GSF.xx files replacing the last call to NAMEL1ST1 with NAMELIST_EX. 


7. SQA Signature & Date: 


Original Signed by 
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2. Date: 

3-1-95 

4. Part of Configuration Item Affected: 

GP_PST_00 1 -02 1 .TC & EX 


5. Reason for Modification: 

The model for GP lest cases has been updated and these test cases need to be regenerated using the new model. 

OeVccLA Ko -SSMiCl ^ \Z : 15* eki.v 


6. Modification: 

All 21 Pluto structural test cases for GP have been regenerated with the new model. 


i vA<r .riedcl ,-i ~5~dC{L It ^ 4 AUc* {'inksJtlQ. 
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3. Formal Modification #: 
21 


1. Configuration Item: 
Verification Cases 


7. SQA Signature & Date: 


Original Signed by 
Kelly Hayhurst 
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1. Configuration Item: 

2. Date: 

3. Formal Modification ft: 

Verification Cases - Driver 

3/1/95 

22 


4. Part of Configuration Item Affected: 

The driver for die structural test eases for Mercury 


5. Reason for Modification: 


The driver file needs to be modified to use the correct test cases. 


6. Modification: 


The driver was modified to build the correct lest ease names. 


7. SQA Signature & Date: 


Original Signed by 
Kelly Hayhurst 
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1. Configuration Item: 

2. Date: 

3. Formal Modification U: 

Verification Cases - Structural Test cases for TDLRSP for Mercury 

3/10/95 

23 

4. Part of Configuration Item Affected: 

The structural test cases, expected values and Mathcmatica driver files for Mercury 


5. Reason for Modification: 




The test eases and expected values files had errors from Mathcmatica because no initial conditions were input, so Mathcmalica did 
not know what to do with them. 


6. Modification: 

The Mathcmatica drivers were corrected by adding a call to the input file and replaced. The Test cases and expected values were re 


— — ■ 1 
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. . Configuration Item: 

2. Date: 

3. Formal Modification ft: 

1 Verification Cases - Models and lest cases. 

3-14-95 

24 


4. Pari of Configuration Item Affected: 

ASP.M, ASP_NR_xxx.TC & EX, and ASP_RO_xxx.TC & EX, GP.M, GP_NR_xxx.TC & EX, and GP_RO_xxx.TC & EX 
SP.M, SP_001.TC & EX, GPSF 001-008.TC & EX, 

FRAME.M, FRAME_001-009.TC & EX 

5. Reason for Modification: 

Models must be updated to reflect new Spec Mod.2.3-7. 


6. Modification: 

1) The ASP.M model has been updated to calculate the mean and standard deviation only if all status are healthy and previous 
cccleralions arc not identical. The test input and expected values files (ASP_NR_xxx.TC & EX and ASP_RO_xxx.TC & EX) have 

occn regenerated. 

2) The GP.M model has been updated to include die MAX function on die RHS of die MAX_NORMAL_VELOClTY 
comparison in table 5.9 and 5.10. The lest input and expected values files (GP_NR_xxx.TC & EX and GP_RO_xxx.TC & EX) have 
been regenerated. 

3) The SP.M model has been replaced by SP_001.M. The new file contains die lest data as well as die calls to the funcdonal 
unit models without directory references for the calls. The lest input and expected values files (SP_001.TC & EX and SP_0()1.TC & 
EX) have been regenerated because the ASP.M model has been changed. 

4) The lest input and expected values files (GPSF_xxx.TC & EX and GPSF_xxx.TC & EX) have been regenerated because 
the GP.M model has been changed. 

5) The FRAME.M model has been updated by removing directory references from calls to individual functional unit models. 
The lest input and expected values files (FRAME_xxx.TC & EX and FRAME_xxx.TC & EX) have been regenerated because the 
ASP.M and GP.M models have been changed. 
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1. Configuration Item: Structural Test Cases for ASP and GP 

2. Date: 

3. Formal Modification U: 25 

'\t£\e\CAX\ OK) CA -rSPTS 

3/14/95 



4. Part of Configuration Item Affected: Structural Test Cases for ASP and GP — 


^Ve£.c«jfL>j 


5. Reason for Modification: 

Structural test cases and the expected results have to be regenerated using die new Mathennaticu model due to Spec Mod 2.3.7. 
uHLi -S'DC 1 ft 


6. Modification: 

The Afatliematica code for ASP and GP was corrected in accordance to Spec. Mod 2.3.7 and die structural test cases were recreated. 


7. SQA Signature & Date: 


Original Signed by 
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1 . Configuration Item: 

2. Date: 

3. Formal Modification #: 

Verification Cases - Structural test cases for Pluto. 

3-14-95 

26 

4. Part of Configuration Item Affected: 
ASP_PST_xxx.TC & EX, GP_PST_xxx.TC & EX 




5. Reason for Modification: 

Structural test ease inputs and expected results must be regenerated with the new model. clKo/Wcc! oncier 




6. Modification: 

Input and expected-values files have been regenerated for Pluto's GP and ASP functional units. ca.^% 


7. SQA Signature & Date: 


Original Signed by 
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1. Configuration Item: RECLP test case # 68 

2. Date: 

3. Formal Modification #:27 

^ ‘ g W-' 

3/14/95 



4. Part of Configuration Item Affected: RECLP_i^068.TC and RECLP_NR_068.EX 


5. Reason for Modification: 

An error was delected in the value to THETA while doing MC/DC testing. THETA had die wrong initial value so dial die expected 
value was calculated wrong. 


6. Modification: 

The correct initial value of Theta was put into test case 68 


error 'VetA 
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1. Configuration Item: 

Verification Cases - model for TDLRSP . 

2. Dale: 
3-30-95 

3. Formal Modification U: 
28 


4. Part of Configuration Item Affected: 

TDLRSP.M, TDLRSP_NR_xxx.TC & EX.TDLRSP_RO_xxx.TC & EX. SP_001.TC & EX, I'RAME_xxx.TC & EX 


5. Reason for Modification: 

The TDLRSP model needs to be corrected to properly assign die value of K_MATRIX for cases not specified in table 5 1 1 and where 
no beams are in lock. 

All TDLRSP requirements based test cases need to be regenerated based on the new TDLRSP model. 

The SP and all FRAME test cases need to be regenerated based on the new TDLRSP model. 


6. Modification: 

’ffom DLRSP mtX,Cl n ° W assigns K - MA ™ X vaIucs properly. Debug print slatcmcnis have been added to help future debugging 

The TDLRSP requirements based lest cases have been regenerated. 

The SP test case has been regenerated. 

The FRAME test cases have been regenerated. 

Ho C-Wxac ^5 cacr'e' Vo V&LK-'bP <-Oi c V^\. respect Vo Vi _(W X. 
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1. Configuration Item: MERCURY Structural Test Cases for 

2. Date: 4/3/95 

3. Formal Modification # 29 

TDLRSP w ,o 

Veg»F>c.ATiftO Ca^ct-6 




4. Part of Configuration Item Affected: MERCURY Structural Test Cases for TDLRSP. 


5. Reason for Modification: 

Structural test cases and the expected results have to be regenerated using tire new Maihermaiica model (SDCR 28) due to an error 
discovered in the TDLRSP Maihemaiica code by the MERCURY tester. 


6. Modification: 

MERCURY Structural lest cases for TDLRSP were recreated using lire Maihemaiica code corrected in SCDR 28. 


7. SQA Signature & Dale: 0rigina , signed by <lkl<}X 

Kelly Hayhurst 


F-151 





Support Documentation Change Report 


page 1 of 1 


1. Configuration Item: 

2. Date: 

3. Formal Modification U: 

Verification Cases 

4-2-95 

30 

4. Part of Configuration Item Affected: 
TDLRSP_PST_xxx.TC & EX 




5. Reason for Modification: 

The expected results Tiles need to be regenerated based on the new TDLRSP.M model. 


6. Modification: 


Pluto structural test cases for TDLRSP arc no longer needed. Test cases from llie TDLRSP requirements based suite have been 
found to provide die same test coverage. The following replacements have been made: 


TDLRSP_PST_001.TC & 
TDLRSP_PST_002.TC & 
TDLRSP_PST_003.TC & 
TDLRSP_PST_004.TC & 
TDLRSP_PST_005.TC & 
TDLRSP_PST_006.TC & 
TDLRSP_PST_0()7.TC & 


EX 

replaced by 

EX 

replaced by 

EX 

replaced by 

EX 

replaced by 

EX 

replaced by 

EX 

replaced by 

EX 

replaced by 


TDLRSP_RO_006.TC & EX 
TDLRSP_RO_026.TC & EX 
TDLRSP_RO_002.TC & EX 
TDLRSP_RO_026.TC & EX 
TDLRSP_NR_021.TC & EX 
TDLR S P_N R_004 .TC & EX 
TDLRSP_NR_003.TC & EX 


7. SQA Signature & Date: " . ~ jdlzrltZ C 
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1 . Configuration Item: 

2. Date: 

3. Formal Modification ft: 

Verification Cases - Trajectory Group 

4-2-95 

31 

4. Part of Configuration Item Affected: 

RUN_TRAJ.COM - support file to run simulator lest cases. 




5. Reason for Modification: 

The directory specific references should be removed from the RUN_TRAJ.COM file so that the user will not need to correct the 
directory reference before running trajectory test cases. 


6. Modification: 

The absolute directory reference has been replaced with a relative reference. 


7. SQA Signature & Date: , , silr>isj ; — 
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1. Configuration Item: 

2. Date: 

3. Formal Modification U: 

Verification Cases 

4-7-95 

32 

4. Part of Configuration Item Affected: 
P_LNK*.COM — files for linking lest support files 




5. Reason for Modification: 

The files listed below have the "/DEBUG" option in the link statement and is very inconvient to use. THe "/DEBUG 1 option should 
be removed because it is unnncccssary. 


P_LNKRECLP.COM 

P_LNKCRCP.COM 

P_LNKCP.COM 


6. Modification: 

The "/DEBUG" options have been removed from the files 


7. SQA Signature & Date: 
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1. Configuration Item: 

2. Date: 

3. Formal Modification ti: 

Verification Cases 

4-7-95 

33 

4. Part of Configuration Item Affected: 

P-*_DRI VER.COM — files for subframe test cases 



5. Reason for Modification: 




The files listed below have Mercury directory references and should be corrected to run pluto files 
P_GPSF_DRIVER.COM 
P_CLP_DRIVER.COM 


6. Modification: 

The Mercury references have been replaced by Pluto directory references. 
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1. Configuration Item: 

2. Date: 

3. Formal Modification tf: 

Verification Cases -- Mercury Structural lest cases 

4-10-95 

34 

4. Part of Configuration Item Affected: 
m_asp_st_004-006.lc, ex 




5. Reason for Modification: 


Wrong model used in generating test cases. 


6. Modification: 

Used correct model from CMS to recreate Uiese test cases. 


7. SQA Signature & Dale: 
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1. Configuration Item: 

2. Date: 

3. Formal Modification #: 

Verification Cases 

4-7-95 

35 


4. Pari of Configuration Item Affected: 
M_RUN_TRAJ.COM 


5. Reason for Modification: 


Due to a change in directory structure the M_RUN_TRAJ.COM file must be corrected to reflect this change. 


6. Modification: 


The directory structure was changed from [DBT.TEST_CASES.TRAJJ to [DBT.TRAJ] in M_RUN_TRAJ.COM.. 


Original Signed by 
Kelly Hayhurst 
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1. Configuration Item: 

2. Date: 

3. Formal Modification U: 

Verification Cases 

4-10-95 

36 

4. Part of Configuration Item Affected: 
AP_PST_002.TC * EX 




5. Reason for Modification: 


This lest case has to be updated to account for die new structure of ASP after PR-27 modifications. Since die structure of ASP has 
changed, die path to reach die decision being tested by the test case is slightly different. 


6. Modification: 

1 he A_ACCELERATION variable for X axis has been changed so that its 3 history values arc different and require die standard 
deviation computation. This leads to die check for extreme values. 
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]. Configuration Item: 
Verification Cases 


4. Part of Configuration Item Affected: 
GP_NR_053.EX 1 , 

TDLR S P_N R_006 . TC & EX 
TDLRSP_PST_*.TC * EX 


5. Reason for Modification: 


2. Date: 3. Formal Modification U: 

4-10-95 37 


The following is a list of files in CMS no longer used in the testing procedure for the given reasons: 


GP_NR_053.EX1 
TDLRSP_NR_006.TC & EX 
TDLRSPJPST_*.TC & EX 


This file has never been part of the GP suite 

This test case has been renamed TDLRSP_RO_006.TC & EX 

During a review TDLRSP test cases for SDCR-28 & SDCR 30, it is discovered that 

there arc requirements based test cases that provide the same coverage. These structural 

test cases are no longer needed. 


6. Modification: 

Files should be removed from CMS 


7. SQA Signature & Dale: 




Original Signed by 
Kelly Hayhurst 


F-159 




Support Documentation Change Report 

page 1 of _L 


1. Configuration Item: 

2. Date: 

3. Formal Modification U: 

Verification Cases 

4-14-95 

38 

4. Part of Configuration Item Affected: 



P_RUN_TRAJ.COM 




5. Reason for Modification: 

The call to TRAJ.COM in this file must be changed to P_TRAJ to accomodate for the name change ofTRAJ.COM to 
P_TRAJ.COM. 


6. Modification: 

Calls to TRAJ.COM changed to P_TRAJ.COM 
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1 . Configuration Item: 

Verification Cases and Procedures Document 


2. Date: 
12-8-94 


3. Formal Modification it:)/ 


4. Part of Configuration Item Affected: 

lest procedures must be modified to be more specific. Details of tile required lest case directory structure must be added. 
Description of test case execution tracking needs to be added. 


5. Reason for Modification: 

DO-178B requires specific test case execution procedures. The tracking of test case execution needs to be added. 


6. Modification: 

A step by step test execution procedure has been added. Appendix D and E has been combined and the appendixes that follow have 
been renumbered. An example of a test log has been added as Appendix F. Titles have been added to the appendixes. 

The original Test Procedure section has been renamed to Test Case Development Procedure. 


1 7. SQA Signature & Date: 


Original Signed by 
Kelly Hayhurst 
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1. Configuration Item: 

2. Date: 

3. Formal Modification U: 

Simulator source code 

3-28-95 

1 

4. Part of Configuration Item Affected: 
TRAJ SIM. EXE 







5. Reason for Modification: 

Trajectory simulator prints out incorrect accuracy data in the ACC_LIM_OUTPUT.DAT file. 


6. Modification: 

Corrected the bug which was producing incorrect data in die file: 
ACC_L1M_0UTPUT.DAT 
when the following occurs 

1) multiple implementations are executed 

2) the accuracy check is performed on an integer or logical 

3) and thcvalue of the driving implementation's variable is zero 


7. SQA Signature & Date: 


Original Signed by 
Kelly Hayhurst 
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